The game crashes when taking a screenshot

[LSpadix]

My operating system is Linux Mint 22.1 Xia, and when I try to take a screenshot, the game crashes with the following two lines of error:

free(): invalid next size (normal)
./run-tsc.sh: line 7: 13093 Aborted (core dumped) ./bin/tsc

Is there something odd going on with this "free()" function?

[Quintus]

Is there something odd going on with this "free()" function?

No. free() is a C stdlib function and perfectly well implemented. There likely is a double free happening somehow, i.e. TSC is freeing memory that has already been freed earlier by TSC code. Please provide a gdb stack trace so we can see where exactly in the code things go wrong. -quintus

[LSpadix]

Sorry, I'm still very new to this stuff. How do I do a "gdb stack trace"?

[Quintus]

Sorry, I'm still very new to this stuff. How do I do a "gdb stack >trace"?

Compile TSC in debug mode (-DCMAKE_BUILD_TYPE=Debug). If you used build-tsc.sh to compile TSC, this is already the case. You can see it if you open build-tsc.sh in your favourite editor.

Then run TSC like this:

$ gdb </path/to/tsc>/bin/tsc
gdb> r
...now play until it crashes. gdb will take control of your terminal again then, while keeping the programme in RAM
gdb> bt
...this will output the stacktrace with file names and line numbers

You can end the debugging session with quit.

The stacktrace contains the complete stack of function invocations that lead to the crash, starting from main(), complete with source code file names and line numbers. This is what makes it so useful.

You can also edit run-tsc.sh to always run TSC with gdb. Change the line

./bin/tsc

to

gdb ./bin/tsc

in order to achieve that.

GDB is incredibly useful for debugging problems like this. It’s worth to learn it. Full docs: https://sourceware.org/gdb/current/onlinedocs/gdb.html/

-quintus

[LSpadix]

It only got worse. The game froze when I took the screenshot and I was not able to move my mouse or alt+f4 to get out of it. I had to kill the process using the task manager and the terminal (I was lucky, because I had to access those programs using my keyboard only). I ran the program using GDB and it gave me more information, but only at the beginning. When the game crashed, it gave me the exact same error and nothing more. However, the message changed a little bit when I tried this error again yesterday. It say "double free or corruption (!frev)", so your hypothesis might be right. I'm trying to see what's going on in void cVideo::Save_Screenshot(void), which is in video.cpp, which is the function that's being called when taking screenshots.

[Quintus]

It only got worse. The game froze when I took the screenshot and I was not able to move my mouse or alt+f4 to get out of it. I had to kill the process using the task manager and the terminal. I ran the program using GDB and it gave me more information, but only at the beginning. When the game crashed, it gave me the exact same error and nothing more. However, the message change a little bit when I tried this error again yesterday. It say "double free or corruption (!frev)", so your hypothesis might be right.

Of course it freezes. The moment it would crash gdb kicks in and freezes the processes. From that point on you need to interact with gdb. That is, you need to move the frozen game window away and work with gdb instead; the game is frozen exactly on the function which crashes. In other words, if you run the game through gdb, the window won’t dissappear in the crash moment, instead the game will freeze. This is because gdb is used to inspect everything exactly as it is in the crash moment. As a consequence, running the game through gdb works best if you play it in windowed mode rather than fullscreen mode. Sorry for not clarifying that. I have worked so often and much with gdb that I simply forget about these trivialities. I basically never run TSC in fullscreen mode exactly because of this. -quintus

[LSpadix]

If you say so, then the situation might be even worse than I though, and that's because I found out that the only way for me to reproduce the crash is to go in fullscreen mode with the highest resolution available for my computer (other resolutions don't crash the game, not even in fullscreen), which is a resolution of 1366x768. I tried to reproduce the crash in a lot of resolutions (including the highest one) while in windowed mode with no success, because the screenshot function actually works and doesn't crash the game in that mode.