...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
...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