Tracking down those pesky GPFs

Coming up in the next C8 release we’ll be providing you with some help for tracking down those pesky GPFs.  We’ll be shipping two variants of the RTL; one the regular RTL, and the other RTL variant with some code added to read embedded debug info, and to decode the names of functions in the call stack and associated line number information.  The decoder-enabled RTL is a drop-in replacement, so you can just copy it over the standard RTL and that’s it.

Let’s take a look at what it gives you, here is a simple program that creates a GPF

Program code to force a GPF

On line 9 we declared a LONG with 8 dimensions, but look at line 29,it’s not hard to accidentally introduce an error like this, and a lot harder to track it down when it only fails intermittently at a customer site.  This what we get if we run this program when compiled with debug info:

GPF with debug info decoded at runtime

As you can see our LOOP causes a GPF because it attempts to access a dimension that does not exist – but with the debug info decoded at runtime we immediately see exactly which line of code caused the problem, as well as seeing the entire call stack.  For those who like to stay away from long debug sessions (and who doesn’t) this will be very handy.  Your end-user can just press the “Log info” button and send you the log text file and then it’s ball in your court. :)