[since Aug 19] More HD crashing woes

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 a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [since Aug 19] More HD crashing woes

Re: [since Aug 19] More HD crashing woes

by _mental_ » Thu Nov 02, 2017 9:16 am

I've added some precautions against 'scope leaking' variables in 57de598.
So they no longer cause an undefined behavior. Referencing such variable outside of its scope is a compilation error.

Please post a new report if there will some crashes with the latest code.

Re: [since Aug 19] More HD crashing woes

by _mental_ » Thu Sep 14, 2017 11:19 am

The problem is ZScript compiler does not add implicit scope for if statement without curly brackets.
So expression after if condition belongs to the current scope allowing errors like I found.

Re: [since Aug 19] More HD crashing woes

by Matt » Thu Sep 14, 2017 10:11 am

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

Re: [since Aug 19] More HD crashing woes

by _mental_ » Thu Sep 14, 2017 4:02 am

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.

Re: [since Aug 19] More HD crashing woes

by _mental_ » Thu Sep 14, 2017 2:52 am

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.

Re: [since Aug 19] More HD crashing woes

by Matt » Wed Sep 13, 2017 12:10 pm

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

Thanks for all your work on this.

Re: [since Aug 19] More HD crashing woes

by _mental_ » Wed Sep 13, 2017 12: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.

Re: [since Aug 19] More HD crashing woes

by Matt » Wed Sep 13, 2017 10: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)

Re: [since Aug 19] More HD crashing woes

by _mental_ » Wed Sep 13, 2017 7: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.

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

by Matt » Tue Sep 12, 2017 9: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)

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

by Matt » Tue Sep 12, 2017 8: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.)

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

by Matt » Tue Sep 12, 2017 12: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 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.

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

by _mental_ » Tue Sep 12, 2017 12:40 pm

Post whole config file please.

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

by Matt » Tue Sep 12, 2017 9: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???

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

by _mental_ » Tue Sep 12, 2017 1: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 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.

Top