Wad crashes Doom2.exe but not Chocolate Doom (W_ReadLump, Z_Malloc, etc)

[Doomkid]

I have here a vanilla wad that runs perfectly in Chocolate Doom, but bizarrely crashes Doom2.exe with a wide array of crash messages.

 

Download "potect.zip" and warp to map03. Depending on which way the wind is blowing, you might get any of the below crash messages:
 

Quote

Z_CT at w_wad.c:510

 

W_ReadLump: only read 8776 of 1291931540 on lump 3738 (the numbers change sometimes)

 

Z_CheckHeap: block size does not touch the next block

 

It also said something about Z_Malloc at one point but I forgot to save it.

 

Doesn't seem to matter if the dehacked patch is applied or not. Any help is of course greatly appreciated! This only seems to affect map03, for whatever reason.

 

potect.zip

[bonnie]

"I have no answers or explanations for you. I can only tell you that I just selected all the sectors, copied them into another map, and saved it back into the wad, and now it works. I can also tell you that I really liked the damage flash palette change. c:

 

I took this screenshot in Slade comparing the two maps and their lumps (map07 is the working map):

 

 

One extra thing to note that isn't on this screenshot is the fact that the fixed map had 156 sectors, while the broken map only had 124 sectors. Also, map analysis in GZDB turned up nothing, but I assume you already tried that. Anyways, to save you the 5 seconds of trouble: potectM3.zip..." is what I WOULD have said except for the fact that putting the map back in the map03 slot breaks it all over again!!! I literally have the exact same map in both map03 and map07, yet only map07 works.

 

Sorry for my horrible deception. I wrote all that before actually putting the map back into map03 so I had no idea that we had a mystery for the ages on our hands.

 

edit: I just tried putting the map into every map slot from 01-07, and every single one works except for map03.

[Doomkid]

Thanks so much for your help bonnie. It turns out, it was the D_COUNTD lump. It's the music from dwango5 map15, but converted from MUS to MIDI by Slade. For some reason, converting it corrupted it, so I (after like 1.5 hours of scratching my head and pulling my hair out and trying literally everything I could think of) just copied the original MUS version from dwango5 and left it that way, and now it works. I appreciate you putting time into this!!

[bonnie]

i am an absolute fool!!! i can't heckin believe i didn't even think about the music

i mean those errors certainly don't sound like corrupted music, but i totally should have at least tried something with the music ;~;

 

at least everything worked out in the end

 

P.S. thank you for not capitalizing the b in bonnie friend c:

[Gez]

This is a bug; Choco should crash too!

 

The first error comes from an error macro. It says the bug comes from w_wad.c at line 510 in the source code; unfortunately this is vanilla Doom and we don't have its actual source code; we only have the "cleaned" version. Assuming it's not changed too much from the original, that would put the problem in W_CacheLumpName().

 

The second error message you posted says it tried to read lump 3738, while potect.wad only has 1051 lumps in total. So it's reading random data in memory because it somehow failed to realize it had read far past the end of the archive.

 

The third is memory related too.

 

It'd be interesting to have an explanation for why the MIDI lump caused these memory issues. A bug in DMX maybe?

[andrewj]

15 hours ago, Gez said:

The second error message you posted says it tried to read lump 3738, while potect.wad only has 1051 lumps in total.

The IWAD has nearly 3000 lumps.

[Gez]

Good point. Assuming DOOM2.WAD, that makes it lump 819 of POTECT, so the WOOD4 patch, which is indeed 8776 bytes. There's still a memory corruption somewhere since it thought it could read 1291931540 bytes from it.