(Basic training) double free or corruption (fasttop) DOUBLE SIGNAL FAULT: Received signal 6, exiting...

[gbudny]

Hi

I checked the most recent version of Openmohaa, and it freezes at the end of the basic training. It's happening when I open the last door to enter the corridor. In this case, the game freezes, instead bring me back to the map with missions. I had to use the kill command to quit Openmohaa.

https://gist.github.com/gbudny/1bd03acfa036e682a03459dcc03071b1

Can you fix it?

[gbudny]

Hi

I checked the most recent version of Openmohaa, and it still freezes at the end of the basic training.

openmohaax86_64-dbg:

https://gist.github.com/gbudny/cc39b1f9d893d27a5274e2d83623cad6

[smallmodel]

Trying to track this down, but I'm not able to reproduce the issue on Windows and Linux

[gbudny]

Trying to track this down, but I'm not able to reproduce the issue on Windows and Linux

Hi

Thank you for the answer.

I checked the most recent version, and it still freezes at the end of the basic training.
However, the game now informs about the issue similar to the Credits:

munmap_chunk(): invalid pointer
DOUBLE SIGNAL FAULT: Received signal 6, exiting...

https://gist.github.com/gbudny/20dc3c643a7836a33845fc2f05fddedf

[gbudny]

Hi

I checked the most recent version, and I still have this issue in the same place:

https://gist.github.com/gbudny/72f4dcad4623f2328268eb0a394a1680

[smallmodel]

Signals were handled incorrectly by the game module. Could you try again? I don't guarantee that'll work

[gbudny]

Hi

Thank you for the answer

I use the GOG version on Ubuntu 22.04

I tried to build it a few times, and I still freezes in the same location, mostly with previous error similar to the credits.

munmap_chunk(): invalid pointer
DOUBLE SIGNAL FAULT: Received signal 6, exiting...

It crashed once with this bug from the title of this issue:

https://gist.github.com/gbudny/c979a947730250ffa93f4f728f08dd7d

I will try to check it on the other computer with an older version of Ubuntu.

[smallmodel]

Could you try using one of these commits:

https://github.com/openmoh/openmohaa/commits/main?after=c901bcf32143a9bdfd42ecc850ecb73925c5df33+104&branch=main&qualified_name=refs%2Fheads%2Fmain

I need to know since when it started crashing

[gbudny]

Hi

Thank you for the answer.

I know that one of the commits from August 19th is causing these issues. I checked the most recent version from that day, and it has this bug too. I don't think it is the one that makes Openmohaa unstable. The list of commits is long. I need some time to check a few other commits from that day.

https://github.com/openmoh/openmohaa/tree/24f82e8e36be19990f5bee6036a1ae9df4f687ad

The most recent version from August 18th doesn't have this bug:

https://github.com/openmoh/openmohaa/tree/a274325f43356c9e7bb36000b87f31c9e91215f4

Please do not make any hard resets of this project. I will try to shorten the list of commits from August 19th that could cause this issue. I locate the correct one.

[gbudny]

Hi

I can confirm that this version from August 19th has this bug too:

https://github.com/openmoh/openmohaa/tree/b9655e3f194895c494be43d7026de437bd239e65

This version from August 19th doesn't have this bug:

https://github.com/openmoh/openmohaa/tree/9825e1e6f2b4cffde1c75f1ce755d7ce9407c6c4

The version that started to cause these issues should be on this page between:
Fixed memory leaks: free all memory allocated by the game module and Formatted source files.

https://github.com/openmoh/openmohaa/commits/main?after=5e23a6b640415985c98c4d43c34b731db6befa39+174&branch=main&qualified_name=refs%2Fheads%2Fmain

I check more versions of Openmohaa tomorrow.

[inequation]

So I'm no longer a contributor to the project, but some elementary software engineering practices still apply here. :)

How about instead of this shotgun debugging, run the newest build in gdb and dump core?

gdb ./openmohaax86_64
(gdb) run
# crash happens
(gdb) bt
# call stack (hopefully with symbols) is printed
(gdb) gcore core.dmp
# core gets dumped to file core.dmp

Then attach both the callstack and the core.dmp file (it's a dump of the process' memory core that a developer can load into their own GDB session to do additional investigation) to this issue.

If the build you use doesn't have debug symbols, you may need to recompile it with debug symbols enabled (doesn't necessarily need to be in debug configuration, just with symbols).

[gbudny]

Hi

Thank you for your advice.

You are right about it.

I'm a regular Linux user.

I remember that you ported some awesome games to Linux.

I didn't know that you were observing this project, and I use GBD tomorrow in this case. I wanted to find this commit because it broke something in so many places of this game. I don't want to encounter this issue in the future.

Smallmodel is making this project so incredible.

I found the last version from August 19th that doesn't have this bug:

https://github.com/openmoh/openmohaa/tree/9b15b27f2878950f1326a0c8f7d4341b2c78eab9

Below is the version from August 19th that started to cause different issues:

https://github.com/openmoh/openmohaa/tree/b9f1530eec12b85bc1242529c9d01105bf8b6eda

There are many differences between them, and here are some things that worked in the first version: (Removed CRT check debug flag)

Mohaa

• It doesn't freeze at the end of the Basic training
• It can load Arzew, and I can see this map above 30 seconds. The second version crashes immediately.
• It doesn't freeze the game when I press the ESC key and Quit the game when Basic training is still active

Spearhead

• It loads the data from the first mission (the loading bar works) and crashes when I press continue. The second version immediately crashes when it starts to load the data from the game.

Mohaa/Spearhead/Breakthrough

• I can skip credits without freezing the whole game
• It doesn't freeze the game when I press the ESC key and Quit the game when Credits are still active.

[gbudny]

Hi

I compiled the most recent version of Openmohaa to show you the moment when the game freezes at the end of the basic training.

https://gist.github.com/gbudny/c490fd5c23dc2a32330ab530a967aa16

https://gist.github.com/gbudny/1d11e9fc88e8b42587e1bb83a7654e2f

This core dump file is 1GB of data, so I uploaded it to Wetransfer.

https://we.tl/t-PwDeTD4jJE

You can download it for seven days.

I don't know if it was necessary, but I used the command RET a few times.

[smallmodel]

A few tweaks were made, related to memory allocation.
In CMake's command-line, append -DDEBUG_MEMORY=1 to enable debug memory mode to be able to track down more precisely the corruption. The game will run slower as all optimizations related to the memory will be turned off.

Next time you make a core dump, also attach all modules openmohaax86_64-dbg, cgamex86_64-dbg and gamex86_64-dbg so the dump file can match with these modules.

[gbudny]

Thank you for the tweaks.

cmake .. -DCMAKE_BUILD_TYPE=Debug -DDEBUG_DROP_ASSERT=1 -DDEBUG_MEMORY=1

I checked the most recent version of this Openmohaa. Now, the game doesn't freeze anymore in this area. However, it crashed once at the end of the Basic training when I didn't use GDB.

It still inform me about the corruption when I quit the game with GDB active:

https://gist.github.com/gbudny/d4ac894a4cdb3db32c6efd56041e4110

Files:

https://we.tl/t-bH6MswXQEy

It crashed once during the loading of the Basic training without GDB, so these are more random crashes now.

I can compile the version from September 6th with this bug when the game freezes if you want to add more tweaks.

I uploaded files from the previous day when I didn't add -DDEBUG_MEMORY=1

https://we.tl/t-UVJp3rdo1a

[smallmodel]

The executable was compiled with GCC and I only tested compiling with Clang. There was a memory corruption using GCC and this was related to the fact that GCC was compiling modules and marking functions with STB_GNU_UNIQUE: it prevents modules from being unloaded with dlclose(). The game module wasn't unloaded, but its tagged memory was freed, hence the corruption.

It's now fixed, when compiling with GCC it mustn't use STB_GNU_UNIQUE anymore.

[gbudny]

Thank you.

It works now.

I rarely use Clang on Linux.