[7a1274a] Hideous Destructor crash on startup

[Matt]

To replicate:
this version of HD

Code: Select all

gzdoom -file [path to HD] -nomusic -noautoload +map range

It seems to be completely random, with long streaks (maybe 5-10 in a row?) of crashes and similar streaks of non-crashes.

3.1.0 does not do this at all.

Compiled GZDoom as "Debug".

[Matt]

I can get neither of the following to crash:

Code: Select all

gzdoom -file [path to HD] -nomusic -noautoload +map range +set playerclass "enforcer"
gzdoom -file [path to HD] -nomusic -noautoload +map range +set playerclass "marksman"

which respectively have the player start with the shotgun and the marksman rifle. Of these two only the latter uses the cameratexture scope.

"specialist" giving the plasma rifle ends up crashing on exit.

Commenting out the rifle zoomed crosshair code does not affect the crash, so it's not some weird thing I'm doing only with the ZM scope and not the Boss scope.

[Matt]

Compiled GZDoom as "Debug".

This crash no longer happens if I compile as Release rather than Debug, but another crash happens that is even more totally random.

To replicate this other crash:

spawn as medic
IDCLEV01 (have not been able to replicate this crash without this)
IDDQD
switch to chainsaw
start killing everything with chainsaw (and maybe sprint and jump around a lot)
if you clear the entire brown room and courtyard, you probably didn't get the crash, though you might exit with a crash or something like:

Code: Select all

*** Error in `/home/mchan223/doom/./gzdoom': free(): invalid next size (normal): 0x0000000003e8e090 ***
/home/mchan223/bin/gzdoom: line 2: 20818 Aborted                 ~/doom/./gzdoom $*

This crash does not necessarily happen while the chainsaw is out, though I have gotten it both while sprinting (in which case the chainsaw isn't even the player's readyweapon) and while sawing something. The crash seems to just happen whenever within that general context of chainsaw + imps + IDCLEV01 + brown room.

This other crash does also happen in 3.1.0.

[_mental_]

In attempt to reproduce startup crash I launched GZDoom at least twenty times with particular player classes and with random one. It never crashed for me.

If you can reproduce it more or less regularly please run the game under GDB and when it will crash check values of f->Func->PrintableName and call->PrintableName variables:

Code: Select all

p f->Func->PrintableName
p call->PrintableName

I assume crash location will be in VMExec_Checked::Exec() function at line 697.

[Matt]

...how do I run GZDoom under GDB? The GDB manual is startlingly unhelpful on this point.

(as for # of tries, with rifleman I can usually get this startup crash in well under 10, but only if I compile as debug not release)

[_mental_]

Run the following command in Terminal:

Code: Select all

gdb --args ./gzdoom -iwad doom2 -file hd <add any other command line options>

When it will load execute run command (or simply press r and Enter).

[Matt]

Got it.

When it's not crashing it seems to load fine, but where I'd normally get that momentary hiccup before the crash it just freezes indefinitely instead, with a window up and nothing drawn on it, and responds to nothing but the kill command, after which I see this:

Code: Select all

...
[New Thread 0x7fffd3fff700 (LWP 31600)]
[Thread 0x7fffd3fff700 (LWP 31600) exited]
[New Thread 0x7fffd3fff700 (LWP 31603)]
[Thread 0x7fffd3fff700 (LWP 31603) exited]
Resolution: 1280 x 720
10 bots read from bots.cfg


map01 - entryway

[New Thread 0x7fffd3fff700 (LWP 31604)]
[Thread 0x7fffd3fff700 (LWP 31604) exited]
[New Thread 0x7fffd3fff700 (LWP 31605)]
[Thread 0x7fffd3fff700 (LWP 31605) exited]
[New Thread 0x7fffd3fff700 (LWP 31606)]
[Thread 0x7fffd3fff700 (LWP 31606) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000f9205e in VMExec_Checked::Exec (stack=0x7ffff7fbe728, 
    pc=0x589c888, ret=0x7fffffffc760, numret=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmexec.h:697
697				if (call->VarFlags & VARF_Native)

Then (and I have no idea if I did this right)

Code: Select all

(gdb) p f->Func->PrintableName
Cannot access memory at address 0x2b415f8
(gdb) p call->PrintableName
Cannot access memory at address 0x7fffffffbd88

EDIT: Tried looking at the console before killing:

Code: Select all

[New Thread 0x7fffd3fff700 (LWP 5258)]
[Thread 0x7fffd3fff700 (LWP 5258) exited]
Resolution: 1280 x 720
10 bots read from bots.cfg


map01 - entryway

[New Thread 0x7fffd3fff700 (LWP 5261)]
[Thread 0x7fffd3fff700 (LWP 5261) exited]
[New Thread 0x7fffd3fff700 (LWP 5262)]
[Thread 0x7fffd3fff700 (LWP 5262) exited]
[New Thread 0x7fffd3fff700 (LWP 5263)]
[Thread 0x7fffd3fff700 (LWP 5263) exited]

Program received signal SIGSEGV, Segmentation fault.
FName::operator== (this=0x103279988, other=...)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/./name.h:75
75		bool operator == (const FName &other) const { return Index == other.Index; }
(gdb) p f->Func->PrintableName
No symbol "f" in current context.
(gdb) p call->PrintableName
No symbol "call" in current context.

[Matt]

For the much less predictable chainsaw crash (which took me like 10 tries to even get once in GDB and I haven't managed to get it since all this morning):

Code: Select all

[Thread 0x7fffd3fff700 (LWP 6298) exited]
[New Thread 0x7fffd3fff700 (LWP 6301)]
[Thread 0x7fffd3fff700 (LWP 6301) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000835ae8 in GC::Mark(DObject**) ()

I couldn't see my cursor at this time and decided not to risk being forced to reboot, so no attempt to call those p commands yet.

[_mental_]

Print commands won't help with any other case except the very first one. Crash after killing isn't quite interesting but freeze before it is.
Try to reproduce it again and when it hangs on black screen switch to GDB and press Ctrl+C there. Execute thread 1 and bt commands and post the output.

EDIT: What is the compiler you are using? And its version please.

[Edward-san]

I couldn't see my cursor at this time and decided not to risk being forced to reboot, so no attempt to call those p commands yet.

Try to disable completely the mouse in the menu. You should be able to see the cursor when you get a crash.

[Matt]

EDIT: What is the compiler you are using? And its version please.

CLANG 3.5.0-10

Also, here's what I'm using to compile:

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..;make -j 4

Try to reproduce it again and when it hangs on black screen switch to GDB and press Ctrl+C there. Execute thread 1 and bt commands and post the output

---

Code: Select all

Max. vertex shader storage blocks: 16
[New Thread 0x7fffd3fff700 (LWP 14678)]
[Thread 0x7fffd3fff700 (LWP 14678) exited]
[New Thread 0x7fffd3fff700 (LWP 14679)]
[Thread 0x7fffd3fff700 (LWP 14679) exited]
[New Thread 0x7fffd3fff700 (LWP 14680)]
[Thread 0x7fffd3fff700 (LWP 14680) exited]
Resolution: 1280 x 720
10 bots read from bots.cfg


map01 - entryway

[New Thread 0x7fffd3fff700 (LWP 14681)]
[Thread 0x7fffd3fff700 (LWP 14681) exited]
[New Thread 0x7fffd3fff700 (LWP 14684)]
[Thread 0x7fffd3fff700 (LWP 14684) exited]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000f9205e in VMExec_Checked::Exec (stack=0x7ffff7fbe728, 
    pc=0x589e0a8, ret=0x7fffffffc760, numret=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmexec.h:697
697				if (call->VarFlags & VARF_Native)
(gdb) Quit
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fbe740 (LWP 14543))]
#0  0x0000000000f9205e in VMExec_Checked::Exec (stack=0x7ffff7fbe728, 
    pc=0x589e0a8, ret=0x7fffffffc760, numret=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmexec.h:697
697				if (call->VarFlags & VARF_Native)
(gdb) bt
#0  0x0000000000f9205e in VMExec_Checked::Exec (stack=0x7ffff7fbe728, 
    pc=0x589e0a8, ret=0x7fffffffc760, numret=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmexec.h:697
#1  0x0000000000f92282 in VMExec_Checked::Exec (stack=0x7ffff7fbe728, 
    pc=0x5796778, ret=0x0, numret=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmexec.h:721
#2  0x0000000000fad96a in VMCall (func=0x27d0a70, params=0x7fffffffcb80, 
    numparams=2, results=0x0, numresults=0)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/scripting/vm/vmframe.cpp:463
#3  0x00000000010315a8 in DStaticEventHandler::PlayerEntered (this=0x406bd70, 
    num=0, fromhub=true)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/events.cpp:863
#4  0x00000000010313fe in E_PlayerEntered (num=0, fromhub=true)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/events.cpp:425
#5  0x0000000000afdf04 in G_DoLoadLevel (position=0, autosave=false)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/g_level.cpp:1043
#6  0x0000000000afd741 in G_InitNew (mapname=0x1b4b6ac "map01", 
---Type <return> to continue, or q <return> to quit---
    bTitleLevel=false)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/g_level.cpp:516
#7  0x0000000000abc661 in D_DoomMain ()
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/d_main.cpp:2705
#8  0x00000000006a21a8 in main (argc=10, argv=0x7fffffffe2d8)
    at /home/mchan223/doom/gzdoom-7a1274ab768e2883da4ff988fc1f75604a6756c6/src/posix/sdl/i_main.cpp:259
(gdb) 

[Matt]

And, for what it's worth, the chainsaw imp crash (which was very easy to replicate when, for other reasons, I had the chainsaw altfire spawn imps to test how +friendly and master relationships worked in deathmatch):

---

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x0000000000835ae8 in GC::Mark(DObject**) ()
(gdb) 
(gdb) Quit
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fbe740 (LWP 8700))]
#0  0x0000000000835ae8 in GC::Mark(DObject**) ()
(gdb) bt
#0  0x0000000000835ae8 in GC::Mark(DObject**) ()
#1  0x0000000000835538 in DObject::PropagateMark() ()
#2  0x000000000083b568 in DThinker::PropagateMark() ()
#3  0x0000000000835bb8 in GC::Step() ()
#4  0x000000000083b152 in DThinker::TickThinkers(FThinkerList*, FThinkerList*)
    ()
#5  0x000000000083af08 in DThinker::RunThinkers() ()
#6  0x0000000000930e53 in P_Ticker() ()
#7  0x00000000008456ba in G_Ticker() ()
#8  0x000000000082b34f in TryRunTics() ()
#9  0x0000000000823cc5 in D_DoomLoop() ()
#10 0x0000000000826ea3 in D_DoomMain() ()
#11 0x0000000000561900 in main ()
(gdb) 

EDIT: For this one (which I'll call the "chainsaw crash" to distinguish it from the one in the OP) I can replace the imp in that summon with a vanilla Doom imp or demon and the crash still happens. It seems to happen much more frequently if I run GZDoom after making a change, then it crashes many times in a row before after a while I get a very long streak in which the crash doesn't happen at all.

...is this a sign that my RAM is dying?

[_mental_]

...is this a sign that my RAM is dying?

Not necessarily, despite my inability to reproduce the crashes with the same compiler most likely it's a software bug.
With faulty RAM you will have various fairly random issues with any software including OS itself.

[Matt]

Everything else works without a hitch, so yes definitely software.

But I've just gone through the packages and none of the dependencies appear to be corrupt or downloaded from some sketchy source or anything...

[Matt]

I strongly suspect this and my other problem are one and the same. Requesting that this be closed as a duplicate.