DescentDevelopers / Descent3

Descent 3 by Outrage Entertainment
GNU General Public License v3.0
2.74k stars 233 forks source link

[Runtime Bug/Crash] Game freezes during intro cutscene #130

Open Jayman2000 opened 3 months ago

Jayman2000 commented 3 months ago

Build Version

07d988e194cfdaf87a86d798bb423af0ff25d096

Operating System Environment

CPU Environment

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.
JeodC commented 3 months ago

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

Jayman2000 commented 3 months ago

The one CMake generated when I compiled this repo.

JeodC commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

JeodC commented 3 months ago

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 commented 3 months ago

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 commented 2 months ago

This may be resolved when #253 is resolved.