64-bit GZDoom does not gracefully handle this memory error

[Rachael]

Okay, first off, I was experimenting with tools and creating maps using SLIGE. And I thought - wouldn't it be cool to compile these maps together and I could just have a stream of random maps to play?

So I used Slige to generate a few levels. And I used Bagheadspidey's tool to unpack them so they could be repacked into a pk3. Well, I didn't know "unwad" had the bug it does, but needless to say, what was intended to become e1m2 became corrupt.

Using the 2.1.1 64-bit version of GZDoom, I loaded it, and needless to say, the system locked up, twice in a row.

I tried it in 32-bit ZDoom, and it said "failed to allocate from process heap." I then tried it in GZDoom 1.9.1 - which was also 32-bit - and same thing. So this is obviously a 64-bit problem, for now.

Now, knowing the map is corrupt, I know this is a simple case of "don't do that!" Okay, I won't. But the problem still is that GZDoom does not handle corrupt maps gracefully - and the fact that any application can completely lock up the system without direct access to the kernel is a bit concerning in itself.

The system in question is a Lenovo Y50-70 notebook with the US keyboard layout. The operating system is Windows 8.1 64-bit. This problem occurred both when using the NVidia 860M GPU (overheating was suspected so this was turned off in the second trial) and the Intel HD 4600 integrated one.

Attached is the pk3 that will bomb the system. It occurs if you load E1M2.

[Graf Zahl]

I think you are actually running out of system memory. It's not a 64 bit problem but a Windows problem. I had the same experience once when I accidentally tried to load several 1000s of text files into Notepad++. The system got progressively slower the more memory got allocated and eventually it became unresponsive.

The 32 bit version never gets this far, its address space will be exhausted long before you run out of system memory.

[Rachael]

True - but the problem still happens with a fresh boot and nearly nothing running. I try to keep my startup clean because it is annoying to wait for the computer to become usable.

What I am guessing is happening, is the 32-bit version bombs out saying it cannot allocate "-1 bytes" - this, to me, says that it is trying to allocate the maximum amount of memory possible. On a 64-bit system, that can be quite a lot. Luckily, 32-bit runs out of address space rather quickly, like you said, but it will take a while before the 64-bit system gets there.

I don't know for sure that's what's happening, but it's my best guess right now.

[_mental_]

I propose to handle this particular case this way. There are some complexities with ignoring broken WAD files, so the game simply stops with a fatal error.

[Graf Zahl]

Added the patch.

[Blue Shadow]

The pull request is still open, by the way.

[Graf Zahl]

That's because I cherry-picked it onto the repo.