[Bug] Server crash when exploding entity ped/vehicle

[Vidie54]

Summary

Destroying a vehicle, shooting a ped with an explosive weapon, or flying a plane into the ground kills the server process on GTAV Enhanced. The fault lands between 1 ms and 4 s after the explosion, with nothing printed — no script error, no resource warning, no console output at all.

Tried debugging file by file to find which function or thread was crashing, but found nothing. Even unloading the core resources of my framework during the search, keeping only oxmysql and the txAdmin monitor loaded, still crashes the server.

While comparing against a Legacy server on the same host, I found that explosionEvent does not deserialise correctly on Enhanced. The field named f164 decodes to a real weapon hash on Legacy (WEAPON_GRENADE, WEAPON_STICKYBOMB, WEAPON_EXPLOSION — matching what the client reports as the death cause), and on Enhanced it returns exactly that value shifted three bits left. For an RPG, Legacy gives 0xB1CA77B1 and Enhanced gives 0x8E53BD88, which is 0xB1CA77B1 << 3 truncated to 32 bits. explosionType is off by one bit (Enhanced returns exactly ×2 the Legacy value), and posX/posY come back as literally 1.0 in every capture. So the bit reader is misaligned and the drift grows through the struct. (AI assistance was used for this comparison — I do not read bit-level encodings myself.)

The two platforms show two faces of the same defect: Linux writes a minidump with SIGSEGV / si_code = SI_KERNEL faulting on a non-canonical source pointer; Windows exits 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN, the /GS cookie check) and writes no dump file.

Issue type

Server

Repro rate

Always

Server build version

FXServer-early-access b111 linux

OS

Windows 11

CPU

Core i5 12400F

GPU

NVIDIA RTX 3060

RAM

32

Storage type

SSD NVMe

Connection type

Ethernet

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

Linux

OS version / distribution

Linux 6.12.90+deb13-amd64

CPU

Ryzen 9 7900 12-Core Processor

RAM

No response

Using txAdmin?

Yes

Hosting provider

Other GSP

Machine type

Dedicated

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

1. Connect to the server and obtain RPG/Grenade/Sticky bomb.
2. Reproduces with all resources loaded, and still reproduces with everything unloaded except oxmysql and monitor.
3. Start exploding peds, or vehicles that are around or spawned by txAdmin.
4. Repeat a few times — each individual destruction is roughly a coin flip, but the server has never survived a short series of them. Crash comes 1 ms – 4 s after an explosion.

Expected Behavior

The vehicle explodes, the wreck is destroyed, and the server keeps running.

Actual Behavior

The process dies 1 ms – 4 s after the explosion with no output. Linux: killed by the kernel (SIGSEGV, SI_KERNEL, si_addr = 0 — a GP fault from a non-canonical pointer, not a null deref). Windows: exit 0xC0000409. Players dropped without a message, txAdmin restarts it.

CancelEvent() does not prevent it in explosionEvent — a handler that logs and immediately cancels still dies in the same tick, with nothing destroyed.

Evidence

1. Crash signature — identical across all 13 Linux dumps, with the full register dump
2. Crashing thread — one dedicated std::thread, all 53 others parked in futex waits; module-offset stack for both artifact

signal 11 (SIGSEGV)
si_code 0x80 (SI_KERNEL)
si_addr 0
faulting RIP libc.musl-x86_64.so.1 + 0x41505
rdx = 0x3e (62)
rdi = rsp+0x32
rcx = garbage in the high bits, differs every run

Additional Context

Can provide all dump files that i have got here privately.

[Gogsi]

Hello, I was able to reproduce the issue with weaponHash (f164) and other fields being shifted. However I could not reproduce a server crash. Can you attach your script for reproduction?

[Gogsi]

A fix for the wrong explosionEvent data has been implemented and is available in August 11 Patch. Please try again and let us know if the issue persists. Thanks for your help!