I’ve been doing a lot of debugging with print statements and I thought maybe the time has come for me to find out how to do a stack trace from the interpreter! I tried Googling it and noticed that Zarf has actually done this in response to a debugging thread that I started! So that makes it look possible at least. How do you do it?
Thanks in advance!
There’s a “debugger” branch in both my Glulxe and CheapGlk repositories on github. Build those, setting VM_DEBUGGER and making sure that libxml2 is available. Then run
glulxe --gameinfo gameinfo.dbg game.ulx
Yeah, it’s all a pain in the butt.
Okay, I got the debugger branch, but I think I still need remedial help - is this the way to set the option?
export VM_DEBUGGER && makeI’m not much of a “sh” user… I don’t think you can add C compiler options that way.
I added “-DVM_DEBUGGER=1” to the CFLAGS line in the Makefile.
(I really want a better way to customize Glulxe compilation. There are now a couple of important options which you have to hack the Makefile or a header file to enable. But the usual answer is autoconfig, which I despise. Could rely on gmake, eww… could include Makefile config statements from another file, eww…)
I never learned autoconfig or an of those nasty things. Thanks for the explanation, I’ll try it.
…later:
Yay! I got it working! So this will output a stack trace if it crashes? Is there a way to output a stack trace from code, while it’s still running?
I’m picking up another conversation here, about profiling:
I’m trying to run the whole thing noninteractively, so I’m ending the game this way:
To stop the/-- game abruptly:
(- quit; -)
When this happens I see this error:
I’m assuming that’s why there’s no dispatch dump file (there’s also no stack trace, although I also compiled with VM_DEBUGGER) - is that right? How can I get the game to exit cleanly enough to produce output?
First, I forgot an option in showing how to start this up. The command looks like:
glulxe -D --gameinfo gameinfo.dbg game.ulx“-D” means activate the debugging features. “–gameinfo gameinfo.dbg” loads the debug info. (The debug info is optional, but if you omit it, stack traces will show only numeric addresses, no function names. You want the function names.)
The debugging system is intended to be interactive, like a C debugger. When this is available in GUI interpreters, the debug console will be a separate window.
When compiled with debugging (and give “-D”), Glulxe will display a stack trace if it crashes. Also, any command starting with a slash is treated as a debug command. So you can type “/bt” to show a stack trace at any time. Of course, if you look at a stack trace during command input, it will show that you’re in the KeyboardPrimitive() routine.
To catch a runtime error, enter “/break RunTimeProblem”, and then perform the action that causes the error. The interpreter will go into debug mode when it hits that function. Debug mode means it only accepts debug commands, so type “/bt” to see where you are. “/print var” will display the contents of a global variable or other symbol.
If your game is crashing at startup (a problem I’ve run into!) you can instead give the “–starttrap” argument, which throws the interpreter into debug mode before Main() begins. Set a breakpoint and then type “/cont” to begin execution.
This is all terribly primitive, which is why it’s not released. There’s no single-stepping, no breakpoints in the middle of functions, no ability to set and mixing debug I/O with game I/O in the same window is clearly wrong. But you can get a stack trace out.
It occurs to me that I should add a “–quittrap” option, which would go into debug mode on a quit statement or @quit opcode. That would catch fatal run-time errors like the one you mention.