[Fixed] [JIT-only?] Crash on exit with abort_m

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[JIT-only?] Crash on exit with abort_m

Postby phantombeta » Sun Oct 20, 2019 7:47 pm

Basically, if you start the game, use the "abort button" and then Alt+F4 after the VM abort, GZDoom will crash. Seems like it might be JIT-only, too. Seems to be related to exit-handling, but this seems to be out of my league.
Doing anything on the console also seems to make the VM abort not trigger, as far as I can tell.

Call stack:


Steps to reproduce:
  • Start a new game with abort_m
  • Use the "Abort button" (it's a starting item. You have to press the fire button twice to trigger it)
  • After the VM abort is triggered, press Alt+F4.
User avatar
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: The United Soviet Socialist Dictatorship of Hueland
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: [JIT-only?] Crash on exit with abort_m

Postby dpJudas » Mon Oct 21, 2019 3:48 am

Tricky to say for sure what's wrong based just on that call stack. A global array destructing at shutdown, which means that VMFrameStack::PopFrame is not allowed to access other global objects (don't know if it does or not without looking at the code).

Perhaps the problem is that GlobalVMStack is not empty, but it is supposed to be at this point?
dpJudas
 
 
 
Joined: 28 May 2016

Re: [JIT-only?] Crash on exit with abort_m

Postby _mental_ » Mon Oct 21, 2019 4:13 am

The problem is PopFrame isn’t called during stack unwinding with JIT enabled. The question is where should it be placed?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [JIT-only?] Crash on exit with abort_m

Postby Graf Zahl » Mon Oct 21, 2019 5:16 am

That's a bit of s problem. Although the JIT can unwind it doesn't destroy any local data the functions may have created, so the internally created stack frames are not cleaned up.
I think the only way to deal with this is to clear the entire VM stack when processing the abort and printing a stack trace.

This still wouldn't help in cases where an exception passes through the JIT and is caught outside D_DoomMain and not rethrown, but AFAIK the only place where this can ever happen is DestroyAllThinkers.
That'd leave two places where the VM stack needs to be cleaned up after abnormal termination: D_ErrorCleanup and DestroyAllThinkers, and both are completely outside the VM's scope so they should be able to clean the stack entirely.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [JIT-only?] Crash on exit with abort_m

Postby _mental_ » Mon Oct 21, 2019 7:21 am

For this case it’s enough to clear global VM stack in D_ErrorCleanup.
DestroyAllThinkers needs it only if exception was thrown in Destroy, right?
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [JIT-only?] Crash on exit with abort_m

Postby Graf Zahl » Mon Oct 21, 2019 7:31 am

Yes. In that case it is likely that some VM stack frame might have been left behind .
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [JIT-only?] Crash on exit with abort_m

Postby _mental_ » Mon Oct 21, 2019 7:55 am

_mental_
 
 
 
Joined: 07 Aug 2011


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests