Instant crash on launch — Scudo "invalid chunk state" in SDL_main, Samsung Galaxy S24+ (Exynos 2400 / Xclipse 940)

[hufgacer]

crash_filtered_clean.txt

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals
• Command & Conquer Generals: Zero Hour
• Other (please specify below)

Operating System

• macOS
• Linux
• Windows
• Other (please specify below)

Bug Description

App crashes instantly on launch, before reaching the main menu. Crash is a Scudo "invalid chunk state" abort occurring inside SDL_main itself, before any BIG-archive or file-system access begins. Reproduced identically across two separate fresh installs/reboots — same offset both times.

Crash log:
GeneralsX: === SDL_main entered ===
GeneralsX: CWD -> /storage/emulated/0/Android/data/me.generalsx.zh/files/GameData (external)
scudo : Scudo ERROR: invalid chunk state when deallocating address 0x20000758f0faaa0
libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 30271 (SDLThread), pid 30247 (SDLActivity)

Native backtrace (tombstone):
#6 pc 00000000005e6024 libmain.so (offset 0x15fc000) (SDL_main+536) (BuildId: 1e6f0b6f876fa15af62afbf339d1223539bf3dc6)
#7 pc 00000000001a0188 libSDL3.so (offset 0x1f8000) (BuildId: c2d504b34adc49d47e3dba3eab584863c6fdac94)
#8 pc 0000000000db8a80 boot.oat (art_jni_trampoline+144)
#10 pc 00000000002ad6da base.vdex (org.libsdl.app.SDLActivity.main+102)

Possibly related to the allocator-conflict class of bug noted in android.md §4.5 (custom TheDynamicMemoryAllocator vs standard operator delete) — may be an uncovered case specific to Exynos/Xclipse, since the original dev build/testing was on an Adreno device (OnePlus Pad 2).

Reproduction Steps

1. Install GeneralsZH-full.apk from Releases
2. Populate /sdcard/Android/data/me.generalsx.zh/files/GameData/Data/ with vanilla .big files from a legitimate EA App (Origin) install of Zero Hour (33 files, no mods)
3. Launch "Generals ZH" from app drawer
4. App closes immediately — crash occurs before any file/asset loading begins

Additional Context

Platform: Android (Samsung Galaxy S24+, SM-S926B, Exynos 2400 / Xclipse 940 GPU, Android 14)

[tarek369]

Thanks for the detailed crash log — it pinpointed the exact bug.

Root cause: The engine has a custom memory allocator (TheDynamicMemoryAllocator) that intercepts global operator delete. To distinguish its own allocations from libc++/SDL3/DXVK allocations, it reads a 4-byte "magic cookie" at a fixed negative offset from every pointer being freed. On Adreno devices (OnePlus), this read silently hits garbage and the check fails gracefully. On Scudo (Samsung/Exynos), the same read touches the allocator's metadata guard region, triggering the "invalid chunk state" abort.

Fix: Added isPoolPointer() which uses mincore() to verify the page is readable before probing the cookie. External pointers now go directly to ::free() without any memory probing. Committed in ba61ec624.

Please re-download the APK from the release page and test. The Exynos 2400 / Xclipse 940 should now launch without the Scudo abort.

[tarek369]

Update: the Scudo fix required more investigation than expected. The mincore()-based approach I tried caused DXVK free-list corruption — the engine's custom operator new/delete intercepts ALL allocations in the process (including DXVK's internal C++ objects), and distinguishing pool vs. non-pool pointers without probing memory is proving very difficult.

The latest APK keeps the original allocator (which works on Adreno/OnePlus) but does NOT fix the Scudo crash yet. The settings menu crash (#2) IS fixed in this build.

I'm keeping this issue open and will work on a proper fix that compiles DXVK with its own operator new/delete so the engine's pool doesn't interfere. This is a more invasive change and needs careful testing.

[Gregware-p]

I can reproduce the same Scudo crash on a Samsung Galaxy Tab S8 Ultra Wi-Fi with a Qualcomm Snapdragon platform.

Device information

• Device: Samsung Galaxy Tab S8 Ultra Wi-Fi
• Model: SM-X900
• Device codename: gts8uwifi
• SoC: Qualcomm Snapdragon 8 Gen 1
• Hardware property: qcom
• Android version: 16
• Android SDK: 36
• Build: X900XXSBEZE1
• APK: v0.2 Android Alpha

The crash occurs immediately after the working directory is successfully changed to GameData. Relevant log :

07-22 10:27:02.205 26750 26750 D nativeloader: Load /data/app/~~Aq31hMB-Yhqa7kL_h-1uhQ==/me.generalsx.zh-uIqO7mbn0khryOpGbLZfvA==/base.apk!/lib/arm64-v8a/libSDL3.so using class loader ns clns-9: ok
07-22 10:27:02.249 26750 26750 D nativeloader: Load /data/app/~~Aq31hMB-Yhqa7kL_h-1uhQ==/me.generalsx.zh-uIqO7mbn0khryOpGbLZfvA==/base.apk!/lib/arm64-v8a/libmain.so using class loader ns clns-9: ok
07-22 10:27:02.280 26750 26750 E BufferQueueProducer: Unable to open libpenguin.so: dlopen failed: library "libpenguin.so" not found.
07-22 10:27:02.280 26750 26750 E me.generalsx.zh: Unable to open libpenguin.so: dlopen failed: library "libpenguin.so" not found.
07-22 10:27:02.292 26750 26781 V SDL     : Running main function SDL_main from library /data/app/~~Aq31hMB-Yhqa7kL_h-1uhQ==/me.generalsx.zh-uIqO7mbn0khryOpGbLZfvA==/lib/arm64/libmain.so
07-22 10:27:02.293 26750 26781 I GeneralsX: === SDL_main entered ===
07-22 10:27:02.301 26750 26781 I GeneralsX: storage: external=/storage/emulated/0/Android/data/me.generalsx.zh/files internal=/data/data/me.generalsx.zh/files
07-22 10:27:02.301 26750 26781 I GeneralsX: CWD -> /storage/emulated/0/Android/data/me.generalsx.zh/files/GameData (external)
07-22 10:27:02.301 26750 26781 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 26781 (SDLThread), pid 26750 (SDLActivity)
07-22 10:27:02.496 26787 26787 F DEBUG   : Cmdline: me.generalsx.zh
07-22 10:27:02.496 26787 26787 F DEBUG   :       #01 pc 000000000005d200 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::die()+12)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #02 pc 000000000005dc50 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportRawError(char const*)+32)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #03 pc 000000000005dbc4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::ScopedErrorReport::~ScopedErrorReport()+16)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #04 pc 000000000005dfe0 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::reportInvalidChunkState(scudo::AllocatorAction, void*)+120)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #05 pc 000000000005f6fc /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidNormalConfig, &scudo_malloc_postinit>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+296)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #06 pc 000000000065518c /data/app/~~Aq31hMB-Yhqa7kL_h-1uhQ==/me.generalsx.zh-uIqO7mbn0khryOpGbLZfvA==/base.apk!libmain.so (offset 0x328c000) (SDL_main+560)
07-22 10:27:02.496 26787 26787 F DEBUG   :       #07 pc 00000000001a0188 /data/app/~~Aq31hMB-Yhqa7kL_h-1uhQ==/me.generalsx.zh-uIqO7mbn0khryOpGbLZfvA==/base.apk!libSDL3.so (offset 0x1f8000)

This therefore does not appear to be limited to Exynos devices. It also occurs on the Snapdragon-based Galaxy Tab S8 Ultra.

[lfu5l]

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals: Zero Hour

Operating System

• Other (please specify below): Android

Bug Description
App crashes reliably with SIGSEGV (null pointer dereference) whenever a unit dies while it was garrisoned inside a container (building/vehicle). Crash happens on the death/redeploy path, not during normal gameplay. Reproduced consistently.

Crash log summary:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000020
Cause: null pointer dereference

backtrace:
#00 W3DTreeBuffer::unitMoved(Object*)+1196
#01 Object::setTriggerAreaFlagsForChangeInPosition()+192
#02 Object::reactToTransformChange(Matrix3D const*, Coord3D const*, float)+220
#03 Thing::setPosition(Coord3D const*)+324
#04 OpenContain::redeployOccupants()+68
#05 Object::reactToTransformChange(Matrix3D const*, Coord3D const*, float)+200
#06 Thing::setTransformMatrix(Matrix3D const*)+156
#07 PhysicsBehavior::update()+1728
#08 GameLogic::update()+776
#09 GameEngine::execute()+88
#10 SDL3GameEngine::execute()+52
#11 GameMain()+292
#12 SDL_main+2936

Looks like W3DTreeBuffer::unitMoved() dereferences a null pointer when it's invoked via the redeploy/reposition path triggered by OpenContain::redeployOccupants() after a garrisoned unit dies. Possibly the tree buffer instance isn't initialized/valid in this code path on Android, or a race between GameLogic teardown of the dead unit and the transform-change callback chain.

Reproduction Steps

1. Install GeneralsZH-full.apk (v0.2 Android Alpha) from Releases
2. Populate GameData/Data with legitimate Steam install .big files
3. Start a Solo Play skirmish/mission on a map with trees
4. Load a unit into a garrison-able structure or vehicle (container)
5. Kill the garrisoned unit (cause its death while still occupying the container)
6. App crashes immediately (SIGSEGV) as the death/redeploy sequence runs

Additional Bug
On the same install, the main menu also renders with an incorrect overall magenta/pink tint across the entire screen (terrain, UI panels, water, everything) instead of normal colors — this may be a separate shader/rendering issue but reporting alongside since it appeared on first launch, before the crash above.

Device Information

• Device: Samsung Galaxy S23 Ultra (SM-S918B)
• SoC: Qualcomm Snapdragon 8 Gen 2 (Adreno)
• Android version: 15 (AP3A.240905.015.A2)
• APK: v0.2 Android Alpha

Full tombstone log

Build fingerprint: 'samsung/dm3qxxx/dm3q:15/AP3A.240905.015.A2/S918BXXS8DYI3:user/release-keys'
Revision: '13'
ABI: 'arm64'
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000020
Cause: null pointer dereference

backtrace:
      #00 pc 0000000000ad7fb0  libmain.so (W3DTreeBuffer::unitMoved(Object*)+1196)
      #01 pc 0000000000841b80  libmain.so (Object::setTriggerAreaFlagsForChangeInPosition()+192)
      #02 pc 00000000008419f0  libmain.so (Object::reactToTransformChange(Matrix3D const*, Coord3D const*, float)+220)
      #03 pc 00000000006bfd34  libmain.so (Thing::setPosition(Coord3D const*)+324)
      #04 pc 0000000000824c18  libmain.so (OpenContain::redeployOccupants()+68)
      #05 pc 00000000008419dc  libmain.so (Object::reactToTransformChange(Matrix3D const*, Coord3D const*, float)+200)
      #06 pc 00000000006bfbc4  libmain.so (Thing::setTransformMatrix(Matrix3D const*)+156)
      #07 pc 00000000008c26d4  libmain.so (PhysicsBehavior::update()+1728)
      #08 pc 000000000094533c  libmain.so (GameLogic::update()+776)
      #09 pc 000000000065b78c  libmain.so (GameEngine::execute()+88)
      #10 pc 0000000000a5c408  libmain.so (SDL3GameEngine::execute()+52)
      #11 pc 0000000000657d24  libmain.so (GameMain()+292)
      #12 pc 0000000000655ad4  libmain.so (SDL_main+2936)
      #13 pc 00000000001a0188  libSDL3.so

[tarek369]

A build that should address this is now up: v0.3-android. Please retest when you can.

Why v0.2 didn't fix it: the Scudo mitigation that was intended for v0.2 — hiding the engine's operator new/delete from the dynamic symbol table so DXVK/libc++/SDL3 allocations stop reaching the pool's operator delete — was committed ~55 minutes after v0.2 was published, so v0.2 never had it. Your invalid chunk state when deallocating in SDL_main is exactly the symptom of an external allocation being routed through the pool's magic-cookie probe.

v0.3 is built from current HEAD and includes that symbol-hiding (commit 467d129cc), so external .so allocations no longer hit the pool operator delete at all.

Could you reinstall v0.3 (uninstall v0.2 first if you get a signature prompt) and report back whether it launches on your S24+? If it still aborts, a fresh bug-report/logcat with the new libmain.so would be the fastest path to the next fix — the Scudo path is tracked but real-device logs are what unblocks it.

[Gregware-p]

A build that should address this is now up: v0.3-android. Please retest when you can.

Why v0.2 didn't fix it: the Scudo mitigation that was intended for v0.2 — hiding the engine's operator new/delete from the dynamic symbol table so DXVK/libc++/SDL3 allocations stop reaching the pool's operator delete — was committed ~55 minutes after v0.2 was published, so v0.2 never had it. Your invalid chunk state when deallocating in SDL_main is exactly the symptom of an external allocation being routed through the pool's magic-cookie probe.

v0.3 is built from current HEAD and includes that symbol-hiding (commit 467d129cc), so external .so allocations no longer hit the pool operator delete at all.

Could you reinstall v0.3 (uninstall v0.2 first if you get a signature prompt) and report back whether it launches on your S24+? If it still aborts, a fresh bug-report/logcat with the new libmain.so would be the fastest path to the next fix — the Scudo path is tracked but real-device logs are what unblocks it.

Tested again with the v0.3 APK. Unfortunately the crash is still reproducible on my Samsung Galaxy Tab S8 Ultra (SM-X900, Qualcomm/Snapdragon, Android 16).

The APK update was successful. Note that dumpsys still reports versionName=0.1-android, but libmain.so has a different BuildId than the previous release, so the new native binary is definitely installed.

v0.3 libmain.so BuildId:
240c65c874e220958d4dee45e244176d0491527f

The crash is now explicitly reported by Scudo:

GeneralsX: === SDL_main entered ===
GeneralsX: storage: external=/storage/emulated/0/Android/data/me.generalsx.zh/files internal=/data/data/me.generalsx.zh/files
GeneralsX: CWD -> /storage/emulated/0/Android/data/me.generalsx.zh/files/GameData (external)
scudo: Scudo ERROR: invalid chunk state when deallocating address 0x20000760becdc40
libc: Fatal signal 6 (SIGABRT)

Backtrace:
#1 scudo::die()
#2 scudo::reportRawError(...)
#3 scudo::ScopedErrorReport::~ScopedErrorReport()
#4 scudo::reportInvalidChunkState(...)
#5 scudo::Allocatorscudo::AndroidNormalConfig,...::deallocate(...)
#6 libmain.so (SDL_main+560)

The libpenguin.so warning is still present, but execution continues past it into SDL_main and reaches the GameData CWD before the Scudo abort, so it does not appear to be the immediate cause.