Openai/6965f919-c6ac-8012-a35d-7584aba32707

This conversation was exported from ChatGPT

gpt-5-2-thinking

User: Whats the chance of identifying the root cause of this dump?

Whats the chance of identifying the root cause of this dump?

Assistant: Pretty decent chance of getting to a credible “most likely culprit”, but a much lower chance of proving the exact line …

Pretty decent chance of getting to a credible “most likely culprit”, but a much lower chance of proving the exact line of C/C++ code without symbols / a native crash dump.

What the dump already tells us (high confidence)

This is a native crash (EXCEPTION_ACCESS_VIOLATION) outside the JVM. hs_err_pid103780

The “Problematic frame” is inside PZBullet64.dll. hs_err_pid103780

The crashing thread is the MainThread, and the Java→native call chain shows it happened while doing ballistics / combat hit processing:

• zombie.core.physics.Bullet.updateBallisticsTargetSkeleton(II[F)V (native)
• zombie.CombatManager.processBallisticsTargets(...)
• … updateReticle → GameWindow.logic → frameStep → MainThread.mainLoop hs_err_pid103780

So: something in the Bullet/ballistics native layer dereferenced bad memory while updating the “target skeleton” for a ballistic hit. hs_err_pid103780

What that means for “root cause”

You can usually narrow this down to one of these buckets:

1. Game engine bug in PZBullet64.dll (most direct reading of the log) hs_err_pid103780
2. Bad input reaching the native bullet code (e.g., corrupted/invalid skeleton/bone data, weird array size, unexpected entity state) — often triggered by mods or edge-case gameplay timing
3. Memory corruption earlier (rarer, harder): something else scribbled memory and it only crashed when Bullet touched it

The log even shows the compiled native method is Bullet::updateBallisticsTargetSkeleton and stack mapping references zombie.core.skinnedmodel.model.SkinningBone objects, which fits the “skeleton update” theme. hs_err_pid103780

So… what are the odds?

• 80–90% chance we can identify the area and a likely trigger scenario: “ballistics target skeleton update in PZBullet64.dll during combat/reticle update.” hs_err_pid103780
• 30–50% chance we can pin it to a specific mod / asset / reproducible action (depends on whether the log lists mods, and whether you can reproduce around gunfights / ballistic hits).
• <10% chance we can name the exact native bug (like “null bone pointer in function X”) from this hs_err alone, because we don’t have symbols and CreateCoredumpOnCrash is off. hs_err_pid103780

Fastest way to push this from “likely” to “certain”

If you want, I can tell you exactly what to look for in this same log next (it’s usually in the “VM Arguments / Environment / Modules / Loaded Libraries / problematic thread” sections), but the big practical levers are:

• reproduce with all mods off vs on
• reproduce with ballistics-related mods off first (anything touching guns, hit detection, skeletons/models)
• if possible, turn on crash dump / symbols for better native diagnosis (right now it explicitly says no core file dumped) hs_err_pid103780

If you paste the “Dynamic libraries / Modules” and any “Internal exceptions / Java exceptions / mod list” bits from the same hs_err (or tell me whether this was SP or MP + what weapon/combat was happening), we can usually move from “PZBullet64.dll did it” to “this specific interaction did it.”