Debugging the Undebuggable.
Beyond the Xojo IDE
by Jim McKay – piDog.com
Xojo has an excellent debugger that allows you to inspect values at runtime, step through code and get nice messages when something goes wrong. But sometimes this is not enough.
Have you ever found yourself pulling hair over some odd behavior? Maybe a messageBox isn’t showing up or you’re getting a “Segmentation Fault” in your Linux app.
Looking at the debugger is great, but there is more you can do.
Terminal is my co-pilot:
MacOS and Linux both come with Terminal applications that have almost identical functionality. The important part today is the ability to drop an app on a Terminal window , run the App and see messages that would normally be difficult, if not impossible, to locate.
On MacOS, an app is a bundle (a fancy folder), so this requires one extra step. Open Terminal.app, drop your app on the window, delete the extra space apple added after .app, and type /Contents/MacOS/[My\ Application] (Replace [My \ Application] with the name of your app). You can type the first character or two and press Tab to autocomplete the path names to save time. Hit Return and see if anything prints to the Terminal while you run through the steps to reproduce the behavior you’re trying to fix.
It’s not my segmentaion fault:
On Linux, you may find a situation where you run into a “Segmentation Fault”. This just means that code is accessing memory that either hasn’t been allocated, or has already been released. If the App is killed before Xojo can catch it, you’re out of luck. Running from the command line just gives you a “Segmentation Fault” message and ends the execution. Not much help either. Fortunately, Linux also has a nice built-in debugger called gdb.
To run gdb, open a terminal and type gdb followed by a space and drag your executable to the window. Press Return. If gdb isn’t installed, you’ll need to run “sudo apt-get install gdb” first.
If you’re running from the Xojo IDE, be sure to uncheck “Launch executable after recieving” or use the “Project->Run Paused” menu if running locally.
Once gdb is running, you will type “run”. Run through the steps to cause the crash. gdb should stop execution and let you know that a “Segmentation Fault” has occurred. Now you can get a backtrace. Type “backtrace” or just “bt” and take a look. You’ll see a nice backtrace showing the stack to the current call that crashed your app.
If you need to pause execution at some point, just press control-C. If you need to kill the paused program, type “kill”. Type “quit” to exit gdb. If you want to see a more meaningful backtrace including function names, be sure to build for 64bit.
A Window to your code:
Windows apps don’t have as simple a solution, but there is hope. Microsoft provides debugging tools that should be very helpful. WinDbg can help you dig in deeper than you’d probably like to go.
WinDbg is installed as a part of the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
There’s too much to cover here, but Microsoft provides a nice getting started document: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/getting-started-with-windbg
(Jim is the owner of piDog Software and will be a presenter @ XDC 2019 in Miami Florida)