v1.0.16进入世界崩溃

[X-M-AwA]

日志
https://mclo.gs/f5c8mT6

看样子是cqq指针炸了

bro我求你了别用ai了😭😭😭

[unknowbug]

感谢报告！崩溃点我们已经确认了——进入世界时的内存损坏，和我们正在处理的一个已知问题同源（fillOneChunk 附近），目前主线修复进行中。

不过这份日志有个情况需要说明：里面出现了 0xCAFEBABE、0xDEADBEEF、0xBD 这类调试填充值，以及重复的指令字节。这些一般是调试工具/内存填充机制注入的痕迹——也就是说这份日志里寄存器细节可能被环境污染了，但进入世界崩溃这个事实本身是真实且有效的，对我们很有价值。

方便的话，麻烦用干净环境（原版 + 不带任何内存调试类模组/工具）再复现一次，把新日志发一下，这样能帮我们确认是同一个根因还是环境特有问题。修好后我也会回来 @ 你验证。

[unknowbug]

更新了——1.0.18 已修复，请更新验证。

这次的根因比预想的更讽刺：崩溃是我们自己（CoreSwap 的调试代码）造成的。

1.0.15 起我们给 dll 加了原生崩溃日志 handler（VEH，向量化异常处理），目的是定位用户崩溃点。但 AddVectoredExceptionHandler 在 Java 进程里会干扰 JVM 自己的异常处理——JIT 的 null-check、GC 的 guard page 都是 SEH 预期异常，VEH 抢先执行 StackWalk64/打印重活，反而把 Server thread 的堆搞坏了。崩溃日志里的 0xCAFEBABE/0xDEADBEEF/0xBD 这些填充值，正是 VEH 回溯时注入的调试痕迹。

所以之前回复里说的「日志可能被环境污染」——方向说反了：不是你的环境脏，是我们自己的调试 handler 在现场搅局。抱歉让你当了一回白老鼠 😅

修复：JVM 进程（检测到 jvm.dll 已加载）不装 VEH，交给 JVM 自带的 hs_err 兜底（native 栈也有 dll 偏移，够定位了）。

替换 mods/ 下 jar 到 1.0.18 即可。如果还有崩溃，欢迎再报——这次日志会干净很多。

[sweepikun]

不可以条件编译吗

调试进生产实在是有点神秘

[unknowbug]

补充说明：该问题已在 1.0.18 修复（VEH 干扰 JVM 异常处理，JVM 进程内不装 VEH）。项目已于 2026-08-30 从 C++ 迁移到 Rust（单一 worldgen.dll cdylib），Rust 版无 VEH 机制，此类问题不再适用。C++ 行归档为历史参考。

关闭此 issue，感谢当时的测试反馈。