[BUG] 进入世界即崩溃：JVM 原生崩溃（msvcp140.dll 空指针，1.0.18）

[tlipoca-desu]

现象

CoreSwap 接管主世界 chunk 生成（NOISE 阶段）后，进入世界即触发 JVM 原生崩溃（EXCEPTION_ACCESS_VIOLATION），崩在 JDK 自带的 msvcp140.dll 空指针解引用。已连续复现三次，每次都在 mod 接管 chunk 生成后、首次 fillBlocks（JNI 进 C++）时就崩。

两种触发场景

• 先原版建世界（保存退出）→ 后加载 CoreSwap 重进：能正常进入世界，但进入后立刻触 fatal（日志里 [Mixin] populateNoise intercepted chunk(15,-4) 之后即崩）。
• 直接加载 CoreSwap 新建世界：在**"加入世界"界面就立刻崩**；且因区块尚未保存（仍驻内存），下一次启动会重新生成区块。

崩溃复现记录（三次）：

崩溃日志	时间	线程	运行到崩溃
hs_err_pid1664.log	20:34:16	Worker-Main-3	44.16s
hs_err_pid10708.log	20:35:47	Worker-Main-6	37.91s
hs_err_pid18336.log	22:12:28	Worker-Main-4	22.15s

简单说：只要 CoreSwap 接管主世界 chunk 的 populateNoise（NOISE 阶段），首次 fillBlocks（JNI 进入 C++）就在 msvcp140.dll 里解引用空指针崩溃。这与 #10 所述"进入世界崩溃由 VEH handler 导致"不在同一条路径（本崩溃帧是 C++ 运行库 msvcp140.dll，不是 VEH handler）。

游戏环境

Minecraft 1.20.1
Fabric Loader 0.19.3
Java 21.0.6.0 LTS
Windows 10 64bit (19041.6456)
AMD Ryzen 5 9600X (6C12T)
NVIDIA GeForce RTX 5060 Ti 16G
种子 -1556562625122493351

Mod列表

coreswap 1.20.1-1.0.18
sodium 0.5.13+mc1.20.1
iris 1.7.6+mc1.20.1
fabric-api 0.92.11+1.20.1
modmenu 7.2.2
wthit 8.21.1
xaerominimap 26.4.2
xaeroworldmap 1.45.0
replaymod 1.20.1-2.6.23
minihud 0.27.1
malilib 0.16.3
badpackets 0.4.3

重现步骤

场景 A

1. 用原版 Fabric 配置（不含 CoreSwap）创建世界，保存退出。
2. 往 mods/ 加入 coreswap-1.20.1-1.0.18.jar，启动，确认日志出现 [BenchMod] CoreSwap replace mode: C++ worldgen active。
3. 重进该存档——能进世界，但立刻 fatal。

场景 B

1. 直接以含 CoreSwap 的配置启动，新建世界。
2. 在**"加入世界"界面**即崩溃；下一启动会重新生成区块。

日志

三份原始崩溃日志链接：
hs_err_pid18336.log: https://mclo.gs/MrtzEnE
hs_err_pid1664.log: https://mclo.gs/6lOCNlc
hs_err_pid_10708.log: https://mclo.gs/VjjdYs3

hs_err_pid18336.log 节选（03 次崩溃同帧）：

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fffa0782f58
# Problematic frame:
# C  [msvcp140.dll+0x12f58]
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000000   <- 空指针解引用

调用栈（近一次，hs_err_pid18336.log）：

C  [msvcp140.dll+0x12f58]                          <- 崩溃帧（MSVC 运行库）
j  wg.CppWorldgen.fillBlocks([I[I[[II)I             <- JNI 进入 C++ worldgen
J  ...handler$zze000$coreswap$wgPopulateNoise(...)  <- mod 接管 populateNoise
J  java.util.concurrent.CompletableFuture$UniCompose.tryFire(...)
J  java.util.concurrent.ForkJoinWorkerThread.run()V <- chunk 生成 worker 线程

发现（由Agent协助分析，仅供参考，不代表个人意见）

1. 崩溃帧不在 VEH handler 路径：msvcp140.dll+0x12f58 落在 JDK21 自带的 MSVC 运行库（C:\Program Files\Java\jdk-21\bin\msvcp140.dll，基址 0x7fffa0770000，+0x12f58 = 崩溃 pc 0x7fffa0782f58），是 C++ STL 运行库里的空指针。与图形驱动、Sodium/Iris、VEH handler 均无关。
2. 触发时机：worldgen.dll 在 hs_err_pid18336 中于 20.038s 才 Loaded，崩溃发生在 22.15s——即 DLL 加载后约 2 秒、首次 fillBlocks 批量生成即崩（另外两次分别在 Loaded 后约 0.8s/0.2s 崩）。
3. 崩溃线程：Worker-Main-* / ForkJoinWorkerThread（Minecraft chunk 生成 worker 池），_thread_in_native。
4. 本崩溃不经过 VEH，而是 fillBlocks 内解引用空指针 → 1.0.18 根因并未消除，只是换了崩溃点/触发条件。
5. 产物：worldgen.dll size=355840，sha256=27d0499297e854a6...，加载自 ...\Temp\coreswap-native\worldgen.dll；worldgenDir=...\Temp\coreswap-data\worldgen。

补充分析（由Agent协助分析，仅供参考，不代表个人意见）

• 崩溃在 C++ 侧 fillBlocks（经 JNI 调用）解引用空地址 0x0，属原生代码空指针 / 内存损坏，大概率与并发 batch 或缓存复用（thread_local / FlatCache / Cache2D）有关；当前默认线程数 = hardware_concurrency()（12 逻辑线程），本机为 6 物理核。
• 建议：符号化 msvcp140.dll+0x12f58 定位具体函数；用 -Dcoreswap.threads=1 串行复测排除并发竞争；给出修复版后按场景 A 复测（原版建世界 → 加 CoreSwap → 重进）。若把 v1.0.16进入世界崩溃 #10 视为"已修复并关闭"，那么 1.0.18 在 Java 21 + Windows 10 上仍崩溃，说明 v1.0.16进入世界崩溃 #10 修复不彻底或引入了回归。优先级应设为 P0。

[tlipoca-desu]

根因定位：worldgen.dll 动态 CRT 与宿主 msvcp140.dll 版本不匹配（已实测验证）

补充更新：此崩溃不是用户环境问题，也不是 VEH handler 或线程池问题。根因已定位，且通过从作者原版源码重新编译实测验证，可稳定复现与消除。

根因

worldgen.dll 采用**动态 CRT（/MD）**编译，运行时动态链接到宿主进程的 msvcp140.dll。宿主是 JDK 21，自带 msvcp140.dll 14.36.32532（位于 C:\Program Files\Java\jdk-21\bin\），而 worldgen.dll 是用 VS 14.44（更新的 MSVC 工具链）编译的——两者 CRT / 标准库版本不匹配。

崩溃发生在 C++ 标准库内部（msvcp140.dll+0x12f58）：即 mutex / condition_variable 冷启动时内部句柄访问了空指针（reading address 0x0000000000000000）。这属于 运行库版本冲突，与生成逻辑、并发 batch、VEH handler 均无关。

这解释了"为什么有的机器崩、有的不崩"

关键点：取决于启动器 / JVM 给进程配的 msvcp140.dll 版本。

• 若 JVM 自带的 msvcp140.dll 与 worldgen.dll 的编译版本一致/兼容 → 不崩
• 若版本差代较大（如 JDK21 的 14.36 vs VS 14.44）→ 首次使用 CRT 容器（mutex/condition_variable）即崩

这与"首次 fillBlocks（JNI 进 C++）就崩"的现象完全吻合——第一次真正用到 CRT 同步原语，就撞上版本不兼容。

修复方案（治本，而非绕过）

把 worldgen.dll 改为 静态 CRT（/MT） 编译。改后 dumpbin /dependents 仅剩 KERNEL32.dll，不再依赖进程里的 msvcp140.dll，与宿主运行库彻底解耦。

# worldgen/CMakeLists.txt 添加
cmake_policy(SET CMP0091 NEW)
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

即 MultiThreaded（静态 CRT /MT）。

实测验证

从 1.0.18 原版仓库重新编译，C++ 源码一行未动，仅：

1. 改为静态 CRT（/MT）
2. 一处编译必需的 jint*int* cast

结果：

• dumpbin /dependents → 仅 KERNEL32.dll（不再依赖 msvcp140.dll）
• 进世界 / 建新世界 → 不再崩溃

（说明：以上分析由 Agent 协助完成，并已从作者公开源码 + 仅 /MT 改动实测验证，仅供参考。）

[unknowbug]

感谢这份非常扎实的根因定位与实测验证——动态 CRT（/MD）与宿主 msvcp140.dll 版本不匹配导致冷启动崩溃，/MT 静态 CRT 修复后仅依赖 KERNEL32.dll，分析完全正确。

该问题在 Rust 重写版（1.0.19-beta 起）已彻底消除：单一 worldgen.dll cdylib 由 Rust 编译，不依赖 msvcp140.dll，与宿主 CRT 完全解耦。C++ 行已归档为历史参考。

关闭此 issue，感谢贡献。