[since Aug 19] More HD crashing woes
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.
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.
- 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
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.)
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 25 times
Last edited by Matt on Tue Sep 12, 2017 10:47 pm, edited 1 time in total.
- 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)
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)
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)
Re: [since Aug 19] More HD crashing woes (but replicable)
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:
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.
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.
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.
- 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)
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???
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)
Post whole config file please.
- 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)
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:there is no crash.
EDIT: Replacing that line with thisdoes not prevent the crash.
EDIT: Commenting out the crosshair cameratexture HUD stuff that reads what weaponstatus[2] is does nothing.
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");
}
EDIT: Replacing that line with this
Code: Select all
if(getcvar("hd_vulczoom")){
int vz=getcvar("hd_vulczoom");
vvv.weaponstatus[2]=vz;
}
EDIT: Commenting out the crosshair cameratexture HUD stuff that reads what weaponstatus[2] is does nothing.
- 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)
...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.)
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.)
- 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)
This works just fine, so I'm at a loss:
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)
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
After several tries I managed to reproduce exit crash with 32-bit Debug build for Windows. Although callstack is fairly different:
Meta class being destructed was HDPistolFullAuto and that's all I can add at the moment.
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.
- 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
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)
(This, and the crash-on-exit stan423321 mentioned in the ZScript discussion thread)
Re: [since Aug 19] More HD crashing woes
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.
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.
- 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
Sweet, there's actually something to find this time!
Thanks for all your work on this.
Thanks for all your work on this.
Re: [since Aug 19] More HD crashing woes
The problem is indeed with the following code:
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.
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");
}
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
I implemented a possible workaround for if scoping issue here.
Using it with the latest HD revealed two remaining issues:
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.
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'
I would like to commit my changes to master branch although in theory they may prevent some seemingly working mods from starting.
- 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
Fixed those on my end, thanks! (Somehow I got confused about null versus undeclared in those...)