Eternity crash (2011/07/02) (problem isolated?)

Eternity caused an Access Violation Exception (0xc0000005)
in module Eternity.exe at 001b:004b8b87.

Error occurred at 7/2/2011 21:45:02.
D:\Doom\Eternity.exe, run by ioan.
Operating system: 5.1.2600
1 processor, type 586.
71% memory in use.
1536 MB physical memory.
431 MB physical memory free.
2157 MB page file.
1002 MB paging file free.
2048 MB user address space.
1925 MB user address space free.
Access violation at 0541a318. The memory could not be written.

Context:
EDI: 0x05370620 ESI: 0x0054a788 EAX: 0x04d13834
EBX: 0x005416f3 ECX: 0x00000000 EDX: 0x0541a308
EIP: 0x004b8b87 EBP: 0x00000001 SegCs: 0x0000001b
EFlags: 0x00010202 ESP: 0x0012fee8 SegSs: 0x00000023

Bytes at CS:EIP:
89 42 10 89 4f 0c 89 4f 10 89 4f 08 89 4f 04 f6

Stack:
0x0012fee8: 00000004 0048b5fc 00000001 0048b6fc ......H.......H.
0x0012fef8: 0054a7a1 00437c20 00017711 00000001 ..T. |C..w......
0x0012ff08: 00000000 00000000 00000004 0041cee1 ..............A.
0x0012ff18: 015864c4 00000001 00000005 00000000 .dX.............
0x0012ff28: 00000003 00017711 0001770c 0041d084 .....w...w....A.
0x0012ff38: 015864c4 00000001 0012ff7c 00000000 .dX.....|.......
0x0012ff48: 00000000 0041bd1a 004ab515 004b02e8 ......A...J...K.
0x0012ff58: 015864c4 00000001 00000000 0012ff58 .dX.........X...
0x0012ff68: 0012fb0c 0012ffb0 004cba2a 00500ec0 ........*.L...P.
0x0012ff78: 00000000 0012ffc0 004cb1c2 00000009 ..........L.....
0x0012ff88: 00353148 003538b8 6689b84a 00000018 H15..85.J..f....
0x0012ff98: 00000000 7ffdd000 00000000 00000000 ................
0x0012ffa8: 0012ff90 e5f59606 0012ffe0 004cb381 ..............L.
0x0012ffb8: 66cb4132 00000000 0012fff0 7c817077 2A.f........wp.|
0x0012ffc8: 00000018 00000000 7ffdd000 8054b738 ............8.T.
0x0012ffd8: 0012ffc8 8777f248 ffffffff 7c839ad8 ....H.w........|
0x0012ffe8: 7c817080 00000000 00000000 00000000 .p.|............
0x0012fff8: 015ae9d0 00000000 ..Z.....


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

Oh yeah, the version is Wodanaz downloaded right from this forum. No "beta-level" SVN download or build.

printz said:

Oh yeah, the version is Wodanaz downloaded right from this forum. No "beta-level" SVN download or build.

Which one? There are two release builds.

Oh, it's the Win "Plus" Release. http://eternity.mancubus.net/ee-3.40.15-win32p.zip

Something very bad happened.

Your crash is in ~ZoneObject, the virtual destructor for the base class that all zone-memory-allocatable objects use. For some reason, it died here:

   if(*zoneprev = zonenext)
      zonenext->zoneprev = zoneprev;

This is code which removes the ZoneObject from the objectbytag chains. It appears to be the write to zoneprev to which it suddenly objected.

I think that in order for this to happen, the heap must have been in a corrupt state, but it's difficult to say. I cannot ascertain what subclass the object was of, because almost all ZoneObject descendents do not override the destructor, meaning the compiler has mapped all of its autogenerated dtors to the same code in the executable.

I can however determine that it was a Thinker subclass, because the delete call occured in Thinker::RunThinkers as a result of a call to Thinker::removeDelayed. But which one, and does it really matter? I doubt any of their specific behaviors is the cause of this issue, whatever it may be...

The map triggering it has exactly as many monsters as in the whole of Ultimate Doom (that means including E4, so it's over 2000 or 3000, can't remember). I was also using a monster & weapon Dehacked modification with heavy usage of MBF features. All the monsters were progressively teleporting into an arena which was consisting of much of the level.

If you ask me for the map, I afraid I won't be able to give it to you until after 2 weeks or more.

printz said:

The map triggering it has exactly as many monsters as in the whole of Ultimate Doom (that means including E4, so it's over 2000 or 3000, can't remember). I was also using a monster & weapon Dehacked modification with heavy usage of MBF features. All the monsters were progressively teleporting into an arena which was consisting of much of the level.

If you ask me for the map, I afraid I won't be able to give it to you until after 2 weeks or more.

I'd lean more heavily toward the DeHackEd patch being the source of the issue, since C++ EE has been stress tested against such wads as nuts and Sunder without any apparent problems. The number of enemies on a map doesn't affect the stability or behavior of the game engine in any verifiable manner. But changing the game logic to introduce unusual and possibly still-untested combinations of features could easily bring to the surface some small mistake made somewhere that is corrupting the thinker list and/or the zone heap.

Ideally I'd like to have both, though. If I can test them together that stands the best chance of reproducing inside the debugger.

Could it also be the computer's fault? It happened on an older, possibly infected (or aged) system. Or is the processor memory protection so low-level it's impossible to break from a virus or system issue, so it MUST be an Eternity/mod bug?

printz said:

Could it also be the computer's fault? It happened on an older, possibly infected (or aged) system. Or is the processor memory protection so low-level it's impossible to break from a virus or system issue, so it MUST be an Eternity/mod bug?

It's not impossible, but it's extremely unlikely and should always be the last thing suspected. If at all possible, please send me or otherwise link me to the files that you were using so that I can test them in the debugger.

This could be indicative of a very serious architectural issue and there is no other way to approach solving it.

It seems that now it quits sanely with an error. It happens with Wodanaz Plus.

Here's the error message:

Z_Free: freed a pointer with invalid tag 0
Source: ..\source\z_native.cpp:981

It happens when you reset the level after you die in a fight with a cyberdemon shooting mushroom-spawning rockets. Here's the Dehacked batch:

http://pastebin.com/awJyxuVJ

Just use this patch, go to E2M8 and try to defeat that Cyberdemon with all you've got, and let him kill you. Eventually, this bail will occur.

I didn't even get to SEE the monster before the debug build managed to break into the debugger with this:

HEAP[Eternity.exe]: HEAP: Free Heap block b9562c8 modified at b9562fc after it was freed
Windows has triggered a breakpoint in Eternity.exe.

This may be due to a corruption of the heap, which indicates a bug in Eternity.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Eternity.exe has focus.

The output window may have more diagnostic information.

The call stack is, as previously posited from the crash dump information, the following:

• D_DoomMain
  
• TryRunTics
  
• RunGameTics
  
• G_Ticker
  
• P_Ticker
  
• Thinker::RunThinkers
  
• Thinker::removeDelayed
  
• Mobj::`scalar deleting destructor' (auto-generated stub)
  
• ZoneObject::operator delete
  
• Z_Free
  
• free
  

However the heap corruption problem had to occur earlier than this, so I have a lot more work to do.

Found the source of the problem. It's old, very old in fact. From MBF:

   for(i = -n; i <= n; i += 8)    // launch mushroom cloud
   {
      for(j = -n; j <= n; j += 8)
      {
         Mobj target = *actor, *mo; // Oh my GOD this does not work!
         target.x += i << FRACBITS;    // Aim in many directions from source
         target.y += j << FRACBITS;
         target.z += P_AproxDistance(i,j) * misc1;         // Aim fairly high
         mo = P_SpawnMissile(actor, &target, ShotType,
                             actor->z + DEFAULTMISSILEZ);  // Launch fireball
         mo->momx = FixedMul(mo->momx, misc2);
         mo->momy = FixedMul(mo->momy, misc2);             // Slow down a bit
         mo->momz = FixedMul(mo->momz, misc2);
         mo->flags &= ~MF_NOGRAVITY;   // Make debris fall under gravity
      }
   }

What I don't understand is why this is just now suddenly acting like a problem after all these years.
EDIT:
Figured that out too. It's because now that Mobj is based on ZoneObject, and ZoneObject has a destructor, the stack-allocated bitwise copy of the original Mobj falling out of scope causes information related to the original Mobj to be corrupted, including the zone objectbytag links.

The problem stems from the combination of the lack of an explicit copy constructor in any of the ZoneObject or Thinker hierarchy of classes and this bizarre abuse of the Mobj type.

EDIT 2: Fixed by adding a new P_SpawnMissile variant that takes an alternate coordinate to shoot the missile toward instead of using the destination object's x/y/z, while preserving as much of the rest of the behavior as possible.

Thank you!