Crashes on MAP30 (savegame bug) about chocolate-doom HOT 15 CLOSED

Comment by raztk, 2007-09-11 10:35:57:

Logged In: YES
user_id=1649691
Originator: NO

I can't reproduce this, but I'll keep trying anyway.

I'll update if I get something.

from chocolate-doom.

Comment by fraggle, 2007-09-11 11:02:18:

Logged In: YES
user_id=25884
Originator: YES

Ah, correction - this was probably around r964. The fix in revision 967 might have fixed this as well.

from chocolate-doom.

Comment by fraggle, 2007-09-13 10:03:41:

Logged In: YES
user_id=25884
Originator: YES

Latest reports. This looks like a savegame issue.

> > OK I just beat it on I'm Too Young to Die (woohoo!) I probably should
> > have been using the protective suits under the icon to stay in the
> > lava... OK I don't notice any problems. I think it's when I load a
> > game that was saved on that level that it likes to freeze. The WAV
> > thing -- didn't notice it again (it doesn't cut out often) and that
> > might even be a problem with the original Doom II for all I know.
>
> Ok then, is it fair to say that on the latest version (968), you still
> get crashes if you load from a save game, but never get crashes if you
> use IDCLEV?
>

Yes, now I'm positive. I just tried playing level 30 on Ultra Violence
with God mode on for a long while, not beating it, just letting a lot
of enemies come on screen and shooting rockets around randomly --
nothing happened. Then i died cause I got hit by the skull cube
(didn't know it did that -- is it really the Soul Cube that's featured
in Doom 3?). So then I started over and did much the same thing but
saved my game and then i tried dying by getting hit by the cube and
then loading my saved game and bingo it crashes almost as soon as I'd
loaded it.

I think it's the combination of there being a lot of enemies on screen
and loading your game into that mess. If you load a game on that level
and there's not a lot of enemies on screen yet it seems to work ok. I
am in the habit of loading and saving a lot.

from chocolate-doom.

Comment by fraggle, 2007-09-13 10:03:59:

• summary: Crashes on MAP30 on Windows --> Crashes on MAP30 on Windows (savegame bug)

from chocolate-doom.

Comment by fraggle, 2007-09-13 10:52:54:

Savegame that should demonstrate the crash.

Files were attached:

• doomsav0.dsg (13306 bytes)

from chocolate-doom.

Comment by fraggle, 2007-09-13 10:52:54:

Logged In: YES
user_id=25884
Originator: YES

File Added: doomsav0.dsg

from chocolate-doom.

Comment by raztk, 2007-09-13 12:01:53:

Logged In: YES
user_id=1649691
Originator: NO

Callstack from GDB:

#0 00421322 A_SpawnFly(mo=0x18f5434) (C:/chocolate-doom/src/p_enemy.c:1965)
#1 00426EE2 P_SetMobjState(mobj=0x18f5434, state=S_SPAWN3) (C:/chocolate-doom/src/p_mobj.c:79)
#2 004278D9 P_MobjThinker(mobj=0x18f5434) (C:/chocolate-doom/src/p_mobj.c:480)
#3 00430914 P_RunThinkers() (C:/chocolate-doom/src/p_tick.c:119)
#4 0043099F P_Ticker() (C:/chocolate-doom/src/p_tick.c:153)
#5 0040AA43 G_Ticker() (C:/chocolate-doom/src/g_game.c:961)
#6 004064A0 TryRunTics() (C:/chocolate-doom/src/d_net.c:597)
#7 00404709 D_DoomLoop() (C:/chocolate-doom/src/d_main.c:442)
#8 00405C5A D_DoomMain() (C:/chocolate-doom/src/d_main.c:1469)
#9 0040D7CB SDL_main(argc=3, argv=0xb60dc0) (C:/chocolate-doom/src/i_main.c:46)
#10 004453BB console_main(argc=3, argv=0xb60dc0) (./src/main/win32/SDL_win32_main.c:217)
#11 00445599 WinMain(hInst=0x400000, hPrev=0x0, szCmdLine=0x241f1b "-iwad c:\wads\Doom2.wad", sw=10) (./src/main/win32/SDL_win32_main.c:353)
#12 00444E18 main() (??:??)

As far as I understand, it crashes at:

fog = P_SpawnMobj (targ->x, targ->y, targ->z, MT_SPAWNFIRE);

p_enemy.c, line 1965

from chocolate-doom.

Comment by fraggle, 2007-09-13 14:16:09:

Logged In: YES
user_id=25884
Originator: YES

Thought so. The savegame loading code NULLs out the target in all of the mobjs in the level. In most places, a check is made to determine whether the target is NULL or points to something, but there are s few functions that just assume a valid target. Hence, NULL pointer deference.

In DOS Doom it seems that dereferencing a NULL pointer (or the memory area around NULL) in this way didn't cause a crash, so the game just kept on ticking. Obviously real memory managed OSes are much less forgiving.

I need to audit all of the A_* functions (p_enemy.c etc.) and check that there are no functions that assume a target. Ideally, the ones that do should operate on a substitute target - ie. behave like Vanilla Doom.

from chocolate-doom.

Comment by fraggle, 2007-09-13 14:17:43:

Logged In: YES
user_id=25884
Originator: YES

Also notice I already had to deal with a similar thing in P_SpawnMissile.

from chocolate-doom.

Comment by fraggle, 2007-09-14 08:53:32:

• summary: Crashes on MAP30 on Windows (savegame bug) --> Crashes on MAP30 (savegame bug)

from chocolate-doom.

Comment by raztk, 2007-09-14 22:42:24:

Logged In: YES
user_id=1649691
Originator: NO

Crash in r971:

"Program received signal SIGFPE, Arithmetic exception."

Callstack:

#0 0042127F A_BrainSpit(mo=0x18e98e8) (p_enemy.c:1944)
#1 00426F22 P_SetMobjState(mobj=0x18e98e8, state=S_BRAINEYE1) (p_mobj.c:79)
#2 00427919 P_MobjThinker(mobj=0x18e98e8) (p_mobj.c:480)
#3 00430954 P_RunThinkers() (p_tick.c:119)
#4 004309DF P_Ticker() (p_tick.c:153)
#5 0040AA43 G_Ticker() (g_game.c:961)
#6 004064A0 TryRunTics() (d_net.c:597)
#7 00404709 D_DoomLoop() (d_main.c:442)
#8 00405C5A D_DoomMain() (d_main.c:1469)
#9 0040D7CB SDL_main(argc=3, argv=0xb60cd0) (i_main.c:46)
#10 004453FB console_main(argc=3, argv=0xb60cd0) (SDL_win32_main.c:217)
#11 004455D9 WinMain(hInst=0x400000, hPrev=0x0, szCmdLine=0x241f1b "-iwad doom2.wad", sw=10) (SDL_win32_main.c:353)
#12 00444E58 main() (??:??)

from chocolate-doom.

Comment by fraggle, 2007-09-15 11:08:06:

Logged In: YES
user_id=25884
Originator: YES

Yep. I've fixed the A_SpawnFly bug only for another to appear.

This is actually a Doom bug, and you can crash it in Vanilla DOS Doom as well. Warp to MAP30, wake up the boss, then save the game, quit, start Doom again and load the savegame. After a few seconds the game will crash when a new spitter cube is supposed to be launched.

When you wake up the boss brain, the game finds all of the boss targets in the level and stores them in an array. Then it cycles through the array firing cubes at each target in turn, like this:

braintargeton = (braintargeton+1)%numbraintargets;

If you load from a savegame, the array is never initialised, so numbraintargets=0. So the next time the game tries to spit a cube, it divides by zero and crashes the game.

from chocolate-doom.

Comment by raztk, 2007-09-15 12:13:03:

Logged In: YES
user_id=1649691
Originator: NO

Yeah, I read it on the Doom Wiki too.

Well, I guess the only way to load the game is to warp to MAP30, wake up the boss and only then load the game.

Tricky. :-)

from chocolate-doom.

Comment by fraggle, 2007-09-15 13:25:32:

Logged In: YES
user_id=25884
Originator: YES

I don't think there's much more I can do here. Closing as fixed.

from chocolate-doom.

Comment by fraggle, 2007-09-15 13:25:32:

• labels: --> Compatibility
• status: open --> closed-fixed

from chocolate-doom.