EE 3.40.30.2251 Crashes on HBBeta2.wad Map 29

[Demon of the Well]

Alfheim suicides with an access violation whenever it attempts to load map 29 in HBBeta2.wad, the most recent version of that WAD as of 5/23/2013. The WAD's development thread is here, complete with download. Other ports--GZDooM, PrBooM+, ZDooM--are able to run this map, although ZDooM chokes on it quite a bit on my computer. In the past, I've smoothly run maps larger/more complex/containing more things in this version of EE (never seen this error before at all); it seems to have some kind of problem with this specific map, or the vista of this map's startpoint, or the like.

The engine popped a reporter tool upon crashing, which in turn popped this window, so here you go (quotebomb follows).

.\.........
0x0018fea8: ffffffff 00440566 00000000 00443056 ....f.D.....V0D.
0x0018feb8: 00000006 00000003 00000000 a6acee7c ............|...
0x0018fec8: 0042286d 015c422c 015ca6f8 00000001 m(B.,B\...\.....
0x0018fed8: 0018ff14 00000000 6810129a 0000ffff ...........h....
0x0018fee8: 00000000 0018fed0 00000000 0051e5c0 ..............Q.
0x0018fef8: 0051e5cc 00000000 0051ea24 0051ea2c ..Q.....$.Q.,.Q.
0x0018ff08: 00000000 0042289b 004b60bd 0018ff44 .....(B..`K.D...
0x0018ff18: 004b60c5 004bb318 015ca6f8 00000001 .`K...K...\.....
0x0018ff28: 00000000 0018ff20 0018fa4c 0018ff78 .... ...L...x...
0x0018ff38: 004fab36 0053c858 00000000 0018ff88 6.O.X.S.........
0x0018ff48: 004fa2ca 00000009 00251280 00251990 ..O.......%...%.
0x0018ff58: a6aa74d8 00000000 00000000 7efde000 .t.............~
0x0018ff68: 00000000 00000000 0018ff58 b90e0d8e ........X.......
0x0018ff78: 0018ffc4 004fa48d a6e13210 00000000 ......O..2......
0x0018ff88: 0018ff94 761c33aa 7efde000 0018ffd4 .....3.v...~....
0x0018ff98: 770d9ef2 7efde000 73039725 00000000 ...w...~%..s....
0x0018ffa8: 00000000 7efde000 00000000 00000000 .......~........
0x0018ffb8: 00000000 0018ffa0 00000000 ffffffff ................
0x0018ffc8: 771171d5 0417adc1 00000000 0018ffec .q.w............
0x0018ffd8: 770d9ec5 015f2150 7efde000 00000000 ...wP!_....~....
0x0018ffe8: 00000000 00000000 00000000 015f2150 ............P!_.
0x0018fff8: 7efde000 00000000 ...~....


===== [end of CRASHLOG.TXT] =====

I apologize in advance if I've not gone about reporting this correctly, if it should be obvious to a knowledgeable person that the problem is on my end, or if it's not really relevant given advancing progress on the next named iteration of the engine, but "what the hell, maybe it's of some interest", I figured.

[Quasar]

Demon of the Well said:

I apologize in advance if I've not gone about reporting this correctly, if it should be obvious to a knowledgeable person that the problem is on my end, or if it's not really relevant given advancing progress on the next named iteration of the engine, but "what the hell, maybe it's of some interest", I figured.

Nope that's the exact right thing to do. With that info I can figure out where the crash was and then see if it still happens on trunk. A number of heap corruption problems have already been fixed since Alfheim release so it could simply be related to one of those. Or it could be a different problem entirely.

[Quasar]

Eternity is crashing because it doesn't understand the format of the SEGS lump this map is using.

segs[2] references "side" 3397 of linedef number #0. A linedef has at most 2 sides, so this makes no sense.

Check your node builder format. Eternity does not support "compressed" ZDoom nodes at the current time, nor does it support so-called "DeeP" nodes. If you want Eternity support, you must use uncompressed nodes. This map is far past all vanilla limits in terms of the number of sidedefs (there are over 60500 of them), so it's quite likely your node builder has automatically switched over to a different format, and is using one that Eternity does not support.

[Demon of the Well]

A decisive answer! Thank you. The node format that this map uses must be rarely seen (even in huge maps), for me to never have encountered it before despite using Eternity as my primary port.

[esselfortium]

You should be able to rebuild the nodes using any recent version of ZDBSP to get them in the extended but uncompressed format, and it should work in EE then.