ZDoom

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.

No.

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

Fixed in [url=https://github.com/coelckers/gzdoom/commit/8b46be768695674a04c0a66a1e580ef8b06c7c07]8b46be7[/url].

Please commit this.

Now, missing stack trace can be fixed like [url=https://github.com/alexey-lysiuk/gzdoom/commit/7aaee54119f5e7bfa2e803dc71ca73eda9f6a5f2]this[/url].

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.

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.

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

That's because of [url=https://github.com/coelckers/gzdoom/blob/d4e630c127646a4c762b39c35a8b8f4af73e7d4e/src/win32/i_main.cpp#L1057]this condition[/url]. An exception is re-thrown several times [url=https://github.com/coelckers/gzdoom/blob/d4e630c127646a4c762b39c35a8b8f4af73e7d4e/src/scripting/vm/vmframe.cpp#L560]clearing its message[/url] in process.

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.

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

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

...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]class TestZombie : ZombieMan replaces ZombieMan
{
override void BeginPlay()
{
ThrowAbortException("A terrible error has happened.");
}
}[/code]
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]VM execution aborted: A terrible error has happened.
Called from Object.ThrowAbortException [Native]
Called from TestZombie.BeginPlay at zscript.txt:ZSCRIPT, line 5[/code]
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 [i]immediately close[/i] 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