Unusual crash

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Unusual crash

Post by Zippy »

I stumbled across this unusual crash in GZDoom 1.0.10. I have been informed that it is not GZDoom specific, and should be posted here.

Log:
Spoiler:
The crash occurs when the player lands on a sector with an "Actor Hits Floor" thing. It executes a script whose sole line is

Code: Select all

Thing_Damage( ActivatorTID(), 1000, MOD_FALLING);
The most interesting thing about the crash is that it occurs only if the player naturally advances to the level. If the player starts on the level via command line or IDCLEV it won't crash.

I've done some messing around observing the problem, so if it helps here's some more info:
  • - I've tried changing the script to do just a hudmessage. That worked fine, no crashes.
    - I've tried several different values for Thing_Damage. Lowest was 1 and highest was 3000. All still crashed it.
    - I've tried removing the MOD parameter. It still crashes.
    - I've tried changing the TID parameter to being a literal. It still crashes.
    - I've tried reverting to GZDoom 1.0.04. That version does not crash.
If you need the rest of the crash log (minidump.mdmp etc.) or the wad to inspect, just ask.
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

The crash happens in P_DamageMobj when it is trying to call TakeSpecialDamage. It's the 'call' command that crashes.

I won't have any time the next few days to investigate myself but with the instructions provided this should be reproducable.

I have one further question: Did you assign your player a Tid or not?

And can you post the map? Additional resources aren't necessary. Just the map itself should be enough.
Top
User avatar
Zippy
Posts: 3302
Joined: Wed Mar 23, 2005 5:31 pm
Location: New Jersey

Post by Zippy »

Here's the map the by itself, with the only additional resources included being the compiled ACS library and its plaintext counterpart. The map is still map02, so if you want to see it crash you have to do the quick dash through Doom II's map01 first (since, as mentioned, it doesn't crash if you warp right there.) The player start has been placed right in front of a cliff to jump off of.

Yes, the player gets assigned a TID of 257 in an OPEN script in the library. I'm very positive it does get assigned because I remember running through some debug before and checking to make sure the player was getting a TID.
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Question: Why does G_FinishTravel add the player to the hash chain twice? Once should be enough, shouldn't it?
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Ok, I did some investigations here.

The new code calls P_SpawnPlayer twice now (once in P_SpawnMapThing and again in G_FinishTravel.) and both times it starts the ENTER script for the player. So the ENTER script is executed for the destroyed player object as well and links it in the hash chain. The problem now is, how to fix this? Is it enough to check for OF_MassDestruction in Thing_ChangeTid or are more drastic measures needed? If the script is executed twice it may cause problems with maps that do other stuff in their ENTER script but assume it is only run once. I did just a quick scan through some WADs and found several single-player-only WADs which use ENTER scripts in a way that gets broken by the new behavior.

I added the check to Thing_ChangeTid anyway because this must not happen under any circumstances. That fixes this particular crash at least.
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49223
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Fixed. The dummy player that gets spawned in G_FinishTravel must not attempt to start any scripts whatsoever. This also means it must not set the weapon sprites because they also might start a script.
Top
User avatar
Nash
 
 
Posts: 17484
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:
Contact Nash

Post by Nash »

Yay finally!

Can't wait for the fixed version... the whole "broken ENTER scripts" thing is killing me already.

Great job, Graf and Randy!
Top
Post Reply

Return to “Closed Bugs [GZDoom]”