[Runtime Bug/Crash] Game freezes during intro cutscene

[Jayman2000]

Build Version

07d988e

Operating System Environment

• Microsoft Windows (32-bit)
• Microsoft Windows (64-bit)
• Mac OS X
• Linux: NixOS 23.11

CPU Environment

• x86 (32-bit Intel/AMD)
• x86_64 (64-bit Intel/AMD)
• ARM (32-bit)
• ARM64 (64-bit; sometimes called AArch64)
• Other (RISC V, PPC...)

Game Environment

I’m using the game data from Steam’s Windows version of Descent 3.

Description

If you try to watch the intro cutscene, the game will crash:

Descent 3 Linux Client v1.5.0
Copyright (C) 1999 Outrage Entertainment, Inc.

corrupted size vs. prev_size
SIGNAL 6 caught, aborting
Recursive signal cleanup! Hard exit! AHHGGGG!

Once the game prints “SIGNAL 6 caught, aborting”, it will freeze and do nothing. I have to SSH into the system and send the process a SIGTERM which causes the “Recursive signal cleanup! Hard exit! AHHGGGG!” message.

Regression Status

All I know is that this bug wasn’t in the Windows version of Descent 3 v1.4.

Steps to Reproduce

1. Run Descent3 --windowed.
2. (Optional) Skip the Dolby ad.
3. Wait.

• Game modes affected:
  • Single player
  • Multiplayer competitive
    • Anarchy
    • Hyper-Anarchy
    • Robo-Anarchy
    • Team Anarchy
    • Capture the Flag
    • Bounty
    • Entropy
    • Hoard
    • Monsterball
  • Multiplayer cooperative

• Players affected by issue:
  • Game host
  • Game guests

[JeodC]

Which version of d3-linux.hog are you using?

[Jayman2000]

The one CMake generated when I compiled this repo.

[JeodC]

Only Windows is being forced to build in 32bit. For Linux, at least, Currently CI builds 64-bit executables and d3-linux.hog. In order to build 32-bit you need add -DBITS=-m32 to cmake configure command.. I'm not certain if it's similar for mac. I suggest trying a 32bit build and see if you get the same issue.

[DanielGibson]

This crash happens when nfConfig() in libmve/mvelibl.cpp:665 calls free(nf_buf_cur);, due to a failing consistency check in glibc's free(), which prints "corrupted size vs. prev_size".

Backtrace:

Thread #1 [Descent3] 705086 [core: 20] (Suspended : Signal : SIGABRT:Aborted)	
	__pthread_kill_implementation() at pthread_kill.c:44 0x7ffff74969fc	
	__pthread_kill_internal() at pthread_kill.c:78 0x7ffff74969fc	
	__GI___pthread_kill() at pthread_kill.c:89 0x7ffff74969fc	
	__GI_raise() at raise.c:26 0x7ffff7442476	
	__GI_abort() at abort.c:79 0x7ffff74287f3	
	__libc_message() at libc_fatal.c:155 0x7ffff7489676	
	malloc_printerr() at malloc.c:5,664 0x7ffff74a0cfc	
	unlink_chunk() at malloc.c:1,629 0x7ffff74a17e2	
	_int_free() at malloc.c:4,616 0x7ffff74a2d2b	
	__GI___libc_free() at malloc.c:3,391 0x7ffff74a5453	
	nfConfig() at mvelibl.cpp:665 0x55555583a6f7	
	MVE_rmStepMovie() at mvelibl.cpp:1,236 0x55555583b64c	
	mve_PlayMovie() at d3movie.cpp:511 0x5555557be945	
	PlayMovie() at cinematics.cpp:113 0x5555555a5aff	
	Descent3() at descent.cpp:542 0x5555555ccded	
	oeD3LnxApp::run() at lnxmain.cpp:255 0x555555767569	
	main() at lnxmain.cpp:755 0x55555576746f	

This probably means that metadata of the allocated memory (probably before, maybe after the memory returned to the user) was overwritten by an out-of-bounds read.
I guess ASan could help..

However (@kevinbentley), do I understand it correctly that the libmve code needs to be replaced, because it's some code from Interplay that's not under GPL?

Might make sense to just integrate another MVE decoder to (hopefully) fix the problem, instead of debugging code that needs to go anyway..

[DanielGibson]

By the way, what's the meaning of libmve/ vs lnxmvelib/?

[JeodC]

By the way, what's the meaning of libmve/ vs lnxmvelib/?

Original vs Linux port of the mvelib. Fixing this one might be moot since we need to change that library anyway.

[DanielGibson]

But even on Linux, the code from libmve/ seems to be used..
Confusingly, lnxmvelib/ has a CMakeLists.txt, but is not used by the main cmake file (there's no add_subdirectory(lnxmvelib), only add_subdirectory(libmve))

[JeodC]

This may be resolved when #253 is resolved.