Crash when switching maps

[makrohn]

i'e had this issue in both Polymorphable and Flare, sometimes the game will crash when switching maps. It might be a local issue or a 64-bit issue, but maybe someone else is having it, too. Ubuntu 12.04, 64-bit.

*** glibc detected *** ./polymorphable: double free or corruption (!prev): 0x0000000002577d70 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x7fead45c0626]
./polymorphable[0x47d1ee]
./polymorphable[0x4790c8]
./polymorphable[0x44cf04]
./polymorphable[0x44e70f]
./polymorphable[0x4526bb]
./polymorphable[0x4746f1]
./polymorphable[0x474979]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fead456376d]
./polymorphable[0x404cf9]

It looks almost exactly the same in FLARE.

[clintbellanger]

Either we are deleting the same thing twice, or trying to delete something that was never allocated in the first place. If it's happening on map switch, we can start looking there (various "handleNewMap" routines around the code).

Here's a practice we can try that could help prevent or identify these issues:

• Initialize all pointers to NULL (we often do this unless we're always allocating them in the constructor anyway)
• After deleting something, reset the pointer to NULL
• Check for NULL pointer before deleting something.
• If a pointer was NULL when we expected it to need deletion, output a warning.

In most cases it's a few wasted cycles, but stability is much preferred.

[makrohn]

I think it's actually happening when I enter a map for the second time - so exit and reenter. But that could be my imagination.

*Definitely my imagination.

[stefanbeller]

I tried reproducing this and I have not luck.

Could you compile flare with debugging symbols enabled and then get a backtrace by running flare inside the debugger gdb:

cmake . -DCMAKE_BUILD_TYPE="Debug"
make 
gdb --ex=run --batch ./flare

[makrohn]

I figured it out... it happens if I'm moving to a map which doesn't have a layer which the previous map does (my FLARE at work crashes because I have a test map with a foreground layer there, but the unmodified repo does not, which is why nobody else was getting the error). I thought that, due to a09e0d35abb71894b5f0e1468a8119b0a0ede0ee, I could get away with not putting empty layers into maps that don't use that layer, but apparently something else is getting in the way?

So I can reproduce this in FLARE by re-exporting frontier_outpost.txt with an empty (all 0's) frontier_plains and then running back and forth between frontier_outpost.txt and frontier_plains.txt

*** glibc detected *** ./flare: double free or corruption (!prev): 0x09cbda48 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb7425e42]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb764b51f]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdaPv+0x1b)[0xb764b57b]
./flare[0x80b66b2]
./flare[0x80b25fb]
./flare[0x808bd0e]
./flare[0x808d24e]
./flare[0x8090a22]
./flare[0x80ae37a]
./flare[0x80ae5e9]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73cb4d3]
./flare[0x804b9c1]

[stefanbeller]

@makrohn This commit (get it while it's hot) https://github.com/clintbellanger/flare/commit/11522f616595fb2838bb8c076089bf49d6b042fb is assumed to fix the problem. Thanks to @hean01

[makrohn]

Using the testing method described above, I am still getting the error:

matthew@flaretester:~/flare$ git pull
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 11 (delta 7), reused 8 (delta 4)
Unpacking objects: 100% (11/11), done.
From https://github.com/clintbellanger/flare
   1bac0db..1392f47  master     -> origin/master
Updating 1bac0db..1392f47
Fast-forward
 src/MapRenderer.cpp |   14 ++++++++++++++
 src/MapRenderer.h   |    1 +
 2 files changed, 15 insertions(+)
matthew@flaretester:~/flare$ g++ -I /usr/include/SDL src/*.c src/*.cpp -o flare -lSDL -lSDL_image -lSDL_mixer -lSDL_ttf
src/MapRenderer.cpp: In member function ‘void MapRenderer::clearQueues()’:
src/MapRenderer.cpp:571:10: error: ‘class std::queue<Map_Enemy>’ has no member named ‘clear’
src/MapRenderer.cpp:572:7: error: ‘class std::queue<Map_NPC>’ has no member named ‘clear’
src/MapRenderer.cpp:573:7: error: ‘class std::queue<Event_Component>’ has no member named ‘clear’
matthew@flaretester:~/flare$ ./flare 
1 joystick was found:
  Joy 0) VirtualBox USB Tablet
Using joystick #0.
ignoring unknown key trait_armor_penetrating set to true
ignoring unknown key post_effect set to 40
ignoring unknown key trait_armor_penetrating set to true
ignoring unknown key post_effect set to 40
*** glibc detected *** ./flare: free(): invalid pointer: 0x0a48e718 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb7412e42]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb763851f]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdaPv+0x1b)[0xb763857b]
./flare[0x80b6694]
./flare[0x80b25fb]
./flare[0x808bd0e]
./flare[0x808d24e]
./flare[0x8090a22]
./flare[0x80ae37a]
./flare[0x80ae5e9]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73b84d3]
./flare[0x804b9c1]

[clintbellanger]

Looks like it didn't actually compile a new executable, due to those errors about "has no member named 'clear'"

[makrohn]

It didn't compile with CMake either - stopped at the same point.

[hean01]

Gah, embarassing :), ill fix that..

[hean01]

@makrohn , the fix is now merged into master.

[makrohn]

Confirmed fix!

[clintbellanger]

Yay! Free beer for everyone!