[since Aug 19] More HD crashing woes

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.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

[since Aug 19] More HD crashing woes

Post by Matt »

So somehow I managed to get it so bad that, as of 5ab0f34, I constantly crash every single time I quit. I could find nothing at all that could even conceivably be causing it, and it was fine on 3.1.0, so I went through the list of commits since 3.1.0.

Here are the results from doing the following:
1. Use this version of HD, running as an uncompressed folder rather than a zip
2. Compile as Release (clang version 3.5.0-10, but same thing happens in gcc 4.9.2-10)
3. -nomusic -noautoload +map range
4. Quit once map started

8a7090 august 18 OK
2f5535 august 19 OK

(b8c0e7 august 19 won't compile, will assume the other red X's are what they look like)

1ee323 august 19 crash on start
62cbdd august 20 crash on start
541fac august 28 crash on quit
5ab0f3 september 9 crash on quit
d0fbdd september 11 crash on quit

From the timing of it I would guess it had something to do with the new IWAD finder.

Attaching crashlogs for 1ee323 and d0fbdd.


(I should note that I have both a DOOM2.WAD and a doom2.wad in my doom folder right now, in case that might be relevant.)
Attachments
gzdoom-crash.log.1ee323.zip
(1.77 KiB) Downloaded 24 times
Last edited by Matt on Tue Sep 12, 2017 10:47 pm, edited 1 time in total.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by Matt »

Here are the IWADs I have in my folder:

chex.wad
chex3.wad
DOOM.WAD
DOOM2.WAD
doom2.wad
freedoom1.wad
freedoom2.wad
harm1.wad
HERETIC.WAD
HEXEN.WAD
plutonia.wad
TNT.WAD

plus an "ob.wad" and "ob.old" that happens to be whatever the last OBLIGE map I had played.
(deleting them has no effect)
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by _mental_ »

The latest doesn't crash on startup, right? We don't care about some old commit if it was not released as a stable version.

Log of exit crash is pretty useless as even a function name is missing in frame #3:

Code: Select all

#1  0x000000000055f1bc in ?? ()
No symbol table info available.
#2  <signal handler called>
No locals.
#3  0x000000000091f44c in ?? ()
No symbol table info available.
#4  0x00000000005618a1 in call_terms() ()
No symbol table info available.
To be able to tell something meaningful it's better to have line numbers too.
Please enable debugging information for Release or build RelWithDebInfo or Debug configuration.

P.S. And yes, I cannot reproduce this crash in my Debian 8 VM.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by Matt »

d0fbdd relwithdebinfo and debug crashlogs attached.

There is also a crash when I start a new game or IDCLEV or map (but not changemap) when I am in a game, or if I type endgame and then quit.


EDIT: I was able to get rid of the crash by deleting a large chunk of my gzdoom.ini.
It does not even crash if I delete that chunk, run GZ+HD, quit, then run it again and quit again, so it's not something that HD is systematically re-introducing but some old kipple left over from something else.

This would explain why:
1. it only happens in HD (presumably the offending lines are old HD cvars)
2. it only happens to me (bunch of stuff that only exists in my particular configuration files)
3. it happens on quit, when GZDoom is writing to the ini

I'll try later to isolate just what part of that ini is causing this.

I don't want to have this closed, though, since surely there must be a more graceful, informative way to detect whatever sort of error is going on here???
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by _mental_ »

Post whole config file please.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by Matt »

Will do once I get home - on my rush out to work I forgot to email it myself -_-

EDIT: Here it is. I can get rid of the crash by deleting the entire [Doom.Player.Mod] section.

EDIT: I've narrowed it down to the line "hd_vulczoom=1".
If I delete that, or set it to zero, or comment out the following line in HD like so:

Code: Select all

        if(countinv("Vulcanette"))
            let vvv=vulcanette(findinventory("vulcanette"));
            if(vvv){
                if(getcvar("hd_vulcsuper"))vvv.weaponstatus[0]|=VULCF_FAST;
//                if(getcvar("hd_vulczoom"))vvv.weaponstatus[2]=getcvar("hd_vulczoom");
            } 
there is no crash.

EDIT: Replacing that line with this

Code: Select all

                if(getcvar("hd_vulczoom")){
                    int vz=getcvar("hd_vulczoom");
                    vvv.weaponstatus[2]=vz;
                }
does not prevent the crash.


EDIT: Commenting out the crosshair cameratexture HUD stuff that reads what weaponstatus[2] is does nothing.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by Matt »

...this is a bug in HD. (or is it?)

There are no curlyfriends helping that if countinv vulcanette check, which means that it's trying to set a null (or should be null) "vvv". I'll have to fix this entire function.

That is so weird that it doesn't just crash to console with an address zero error and line number though.


EDIT: So I fixed it, but now that I look at that green and pink it seems it shouldn't have needed fixing??? Shouldn't vvv be null after that let anyway?

(I should stress that I didn't have this problem in 3.1.0.)
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes (but replicable)

Post by Matt »

This works just fine, so I'm at a loss:
Spoiler:
Even weirder... after deleting the curly braces again on the offending bit of the HD code I can replicate the crash with hd_vulczoom, but not with hd_vulcsuper which is in almost exactly the same place. Even if I replace |=VULCF_FAST with =getcvar("hd_vulcsuper")*VULCF_FAST.


EDIT: If I replace the both "hd_vulczoom"s in that line with another CVARINFO-defined cvar, "hd_zmzoom", the crash still happens.

Swapping the two hd_vulc* conditonal lines within that block makes no difference.


EDIT: Renaming the variable to "vvvvvv" (which unlike "vvv" is completely unused elsewhere in HD) also does not prevent the crash.

(also confirmed still happens in e4c9784)
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes

Post by _mental_ »

After several tries I managed to reproduce exit crash with 32-bit Debug build for Windows. Although callstack is fairly different:
Spoiler:
FStateLabel::Children had 0x00000001 as a value which is apparently not valid pointer.
Meta class being destructed was HDPistolFullAuto and that's all I can add at the moment.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes

Post by Matt »

That doesn't look anything like what I've been dealing with, beyond "crash on exit" and "invalid pointer", but it would not surprise me to find that it is related.

(This, and the crash-on-exit stan423321 mentioned in the ZScript discussion thread)
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes

Post by _mental_ »

So far I tracked it down to player enter event and hope to find out more tomorrow. This issue requires some efforts to debug.
It's a random memory corruption but it has a regular pattern at the time. Can be code generation issue or some logic error in rarely used function.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes

Post by Matt »

Sweet, there's actually something to find this time!

Thanks for all your work on this.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes

Post by _mental_ »

The problem is indeed with the following code:

Code: Select all

if(countinv("Vulcanette"))
    vulcanette vvv=vulcanette(findinventory("vulcanette"));
    if(vvv){
        if(getcvar("hd_vulcsuper"))vvv.weaponstatus[0]|=VULCF_FAST;
        if(getcvar("hd_vulczoom"))vvv.weaponstatus[2]=getcvar("hd_vulczoom");
    }
Formatting here is misleading and only the second line belongs to if(...) scope.
I think scoping rules without curly brackets are very strange and usage of vvv in lines 3 and below should cause a compilation error.
Probably it's not so easy to do and that's why it works this way.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [since Aug 19] More HD crashing woes

Post by _mental_ »

I implemented a possible workaround for if scoping issue here.

Using it with the latest HD revealed two remaining issues:

Code: Select all

Script error, ":zscript/playerdeath.txt" line 84:
Unknown identifier 'pc'
Script error, ":zscript/grenade.txt" line 202:
Unknown identifier 'wp'
Those are potential culprit for random memory overwrites.

I would like to commit my changes to master branch although in theory they may prevent some seemingly working mods from starting.
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

Re: [since Aug 19] More HD crashing woes

Post by Matt »

Fixed those on my end, thanks! (Somehow I got confused about null versus undeclared in those...)
Post Reply

Return to “Closed Bugs [GZDoom]”