r1198 Crash with Sonnyboy's map

[Enjay]

Map can be found here:

http://forum.zdoom.org/viewtopic.php?f= ... 2&p=549064

GZdoom crashes with an error messages telling me that map02 is empty. This may be true but the last release version of GZdoom does not crash for me, nor does Zdoom SVN. They just drop to the console telling me that the map is empty.

To repeat, load Sonnyboy's WADs, start a game on map01 and IDCLEV to map02. There are other ways to get the crash but they don't always result in it happening. This method reliably gets the crash for me.

[Graf Zahl]

Any error during map load will mess up the engine's state pretty thoroughly and it's mostly random if this ends in a crash or not. No idea if it's fixable. I've tried for years to get to the bottom of this but so far no luck.

[Gez]

Looking into this a little bit, here's how I can reproduce the crash on both GZDoom r1238 and ZDoom r3276:
- Load with Doom II
- Start game
- idclev02
- quit

When sent to the console screen with the "Map is empty." message, I can most of the time do stuff (such as restarting a new game) without other issues intervening. Only when quitting then does the crash happen.

It might be useful to look into when this started to happen in ZDoom as well, but I don't really feel like running such tests right now.

[Edward-san]

The link for the wad is dead.

[Gez]

Here you go.

It could probably be recreated easily: there's a working MAP01, and a MAP02 in UDMF that's entirely empty -- just the namespace = "zdoom"; line and nothing after that.

The bug is that somewhere in the error handling code something seems to be badly deallocated or whatever. In my tries, it doesn't always crash at the same place, but it always crash in a destructor or a cleanup function.

[Edward-san]

What a weird thing... I can't reproduce this in Linux Ubuntu (uhm, I can test in software mode only). I'll check it with Valgrind.

Heh, tons of errors, like invalid read of size x, conditional jump or move, and other ones. I'll post here the results (removed unnecessary output).

valg.txt

valgrind -v --leak-check=full --track-origins=yes --num-callers=10 ./gzdoom -iwad doom2.wad -file SonnyWad_II.wad > valg.txt 2>&1

(83.34 KiB) Downloaded 78 times

[Gez]

A lot of the problems detected by Valgrind appear to be outside of ZDoom but instead in libasound or libfmodex64. Likewise, the "Conditional jump or move depends on uninitialised value(s)" in the zlib is not something that I'd try to tamper with.

It's not until MAP01 is loaded that the output becomes potentially useful.

By the way, there's a few uninitialized variables that I wonder about. Floordrop can be set to true, but is never explicitly set to false. isExtended is never set to any value. I suppose both rely on everything being zeroed during class construction? It doesn't look safe and I suppose it's worth being made explicit if it silences some of Valgrind's output.

Anyway, I figured catching bogus maps before trying to read data from zero-sized arrays might be more stable, and indeed I don't get crashes at alll anymore.