[Addressed] [since Aug 19] More HD crashing woes

Bugs that have been investigated and resolved somehow.

Moderators: Developers, ZDoom.org Team

[since Aug 19] More HD crashing woes

Postby Matt » Tue Sep 12, 2017 12:43 am

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 2 times
gzdoom-crash.d0fbdd.log.zip
(5 KiB) Downloaded 2 times
Last edited by Matt on Tue Sep 12, 2017 11:47 pm, edited 1 time in total.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby Matt » Tue Sep 12, 2017 1:23 am

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)
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby _mental_ » Tue Sep 12, 2017 2:57 am

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 allExpand view
#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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby Matt » Tue Sep 12, 2017 10:00 am

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???
Attachments
gzdoom-crash.d0fbdd.zip
(14.37 KiB) Downloaded 4 times
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby _mental_ » Tue Sep 12, 2017 1:40 pm

Post whole config file please.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby Matt » Tue Sep 12, 2017 1:57 pm

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 allExpand view
        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 allExpand view
                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.
Attachments
gzdoom.ini.zip
(8.34 KiB) Downloaded 2 times
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby Matt » Tue Sep 12, 2017 9:38 pm

...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
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby Matt » Tue Sep 12, 2017 10:52 pm

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)
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: [since Aug 19] More HD crashing woes

Postby _mental_ » Wed Sep 13, 2017 8:46 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [since Aug 19] More HD crashing woes

Postby Matt » Wed Sep 13, 2017 11:31 am

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)
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: [since Aug 19] More HD crashing woes

Postby _mental_ » Wed Sep 13, 2017 1:08 pm

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [since Aug 19] More HD crashing woes

Postby Matt » Wed Sep 13, 2017 1:10 pm

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

Thanks for all your work on this.
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Re: [since Aug 19] More HD crashing woes

Postby _mental_ » Thu Sep 14, 2017 3:52 am

The problem is indeed with the following code:
Code: Select allExpand view
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_
 
 
 
Joined: 07 Aug 2011

Re: [since Aug 19] More HD crashing woes

Postby _mental_ » Thu Sep 14, 2017 5:02 am

I implemented a possible workaround for if scoping issue here.

Using it with the latest HD revealed two remaining issues:
Code: Select allExpand view
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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [since Aug 19] More HD crashing woes

Postby Matt » Thu Sep 14, 2017 11:11 am

Fixed those on my end, thanks! (Somehow I got confused about null versus undeclared in those...)
User avatar
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests