ZScript: VM stack trace is not printed on VM abort...

[Player701]

...if the VM abort happens immediately after warping to a map by means of a "+map" or "-warp" parameter in the command line.

Consider the following ZScript (also attached to this report):

Code: Select all

class TestZombie : ZombieMan replaces ZombieMan
{
    override void BeginPlay()
    {
        ThrowAbortException("A terrible error has happened.");
    }
}

Now, if you load this script, run GZDoom and start a new game via the main menu, you will get a VM abort message with a stack trace:

Code: Select all

VM execution aborted:  A terrible error has happened.
Called from Object.ThrowAbortException [Native]
Called from TestZombie.BeginPlay at zscript.txt:ZSCRIPT, line 5

This is entirely expected. The buggy behavior occurs when you warp to a map when starting GZDoom with a command-line parameter. Either "+map map01" or "-warp 1" will do the trick. In this case, the error message will not include stack trace output. Not only that, but GZDoom will also immediately close after printing said message. To be able to read it properly, one must enable log file output... and even then, the message will not be of much help if it's a generic VM abort (tried to read from address zero etc.) since there is no stack trace and thus no clue as to what could have gone wrong.

Yes, it is possible to get the stack trace by starting a new game instead of warping directly to a map. I, however, didn't know that at first, and had to set a breakpoint in the source code to be able to debug my script code. Anyway, this kind of behavior is completely user-unfriendly. Please fix it if possible by making GZDoom print a stack trace and show the console with the corresponding error message instead of closing. Even if recovering to a functional state is not possible in this situation, GZDoom shouldn't close completely, and stack trace output should not be missing.

Tested in GZDoom 3.6.0, g3.7pre-266-g426ee2b78, g3.7pre-273-g3e9f531b5

[AFADoomer]

We've been having issues that match the symptoms of this in the current Blade of Agony builds, too. None of us could reproduce it reliably, so we didn't file a bug report... what's odd is that I still get abort exceptions from coding errors, as espected, as far as I can tell.

[_mental_]

That's because of this condition. An exception is re-thrown several times clearing its message in process.

[Graf Zahl]

... all thanks to 'handling' CNoRunExit. In typical ancient ZDoom ways not by doing a proper check but an indirect side effect.

[Graf Zahl]

I was able to fix the missing log window. But the stack trace is going to be a bit tricky because the backtrace logger is not in the correct place and totally misses this particular case. This will have to wait until the asmjit branch gets merged because it has made changes to how the VM invocation works.

[_mental_]

Now, missing stack trace can be fixed like this.

It's for Windows only so far, but if Graf is OK with the change, I'll do it for other platforms too.
Definitely, that NoRunExit thing needs to be checked on Linux and Mac. I guess no message should be be shown at all for that exception which is not the case at the moment.

[Graf Zahl]

Please commit this.

[_mental_]

Fixed in 8b46be7.

[Nash]

Do I still need to disable JIT to see VM stack trace?

[_mental_]

No.

[Graf Zahl]

No, but the VM's stack trace may be incomplete because it performs direct calls into native functions which do not get tracked by the unwinder.