Exception, Assert, Crash

When support issues are raised, it is important to use terminology that can help in the initial triage of the case.  One such term that can be misused is crash.  A program can be described as having crashed, when upon investigation the program is still running and is simply displaying an error dialog with an error number, thus implying a different set of analysis questions, techniques and tools etc.

Before discussing what is a crash and what isn’t, it is also important to remember that Genero architecture is made up of a number of programs running and communicating with each other.  The Dynamic User Interface and Front End protocol have at their historical heart,  the fglrun process on your application server, and a gdc.exe GUI client on your Windows PC (and with Universal Rendering a Javascript process rendering the user  interface).   When introducing GAS and its architecture then you also have dispatcher and proxy processes.  Also throw into the mix, a Database, Genero Report Engine, Four Js License Manager, Browsers, External Web Services and there are many processes communicating with each other.  It is important to identify which of these processes may have stopped, and also to note how other processes react when the process they were communicating with stops unexpectedly.

The first word to look at is Exception.  Genero is an interpreted language, the runner fglrun is interpreting the set of instructions (the p-code) inside a .42m.  An exception is an abnormal event that occurs when interpreting these instructions that can be captured for control.  Using the WHENEVER instruction you can control what happens if an exception occurs, wether the program stops, or if it can continue.  As detailed in an earlier Ask Reuben article , you would typically have a coding standard that dictates what to do if an event occurs.  Benefit of doing so is that if an exception occurs, your Genero application can stop in a tidy manner, display a consistent user interface to the user, record an entry in a log, thus allowing better identification and resolution of such issues etc.

The list of Genero BDL errors gives a list of exceptions and a number.  It should be noted that within area of exceptions, there is a class of non-trappable errors where a Genero application will stop with the documented behaviour as it is not safe to carry on, I discussed non-trappable errors here.

An assertion is some checking built into a program to check that things are as expected before a function is executed.  fglcomp, fglrun have asserts built into them so that they stop when some conditions are not met.  We don’t expect these to be triggered by production releases but occasionally they do.  They will manifest themselves with fglcomp, fglform, fglrun etc stopping and a line written to stderr.  An example is …

Assertion failed: p->type != NULL && p->type->type == typeRecord, file fglcPass2.c, line 7047

We never want to see an assert being triggered so if you ever see an assertion in stderr for fglcomp, fglrun etc we want to know about it and what conditions led to it being triggered.

Worst thing that can happen is the process can crash.  That is stop unexpectedly with no nice error dialog for your user, no useful message written to stderr.  Your support contact will normally be interested in various logs at this point.  Depending on the operating system they might ask you to do certain tasks.  For instance for a process on Windows you might be asked to collect user mode dumps.

It is important to note how processes react when the process they were communicating with stops communicating.  For the common pattern of fglrun on Linux Server and gdc.exe on Windows PC, if the gdc.exe crashed, how does the fglrun process react?  You might see a -6301 or-6302 non-trappable error in the errorlog for the fglrun process.  Similarly if the fglrun process had an exception, what is displayed to the user via the still running gdc.exe process?

There have been support calls that described the problem as the “GDC Crashing”.  Upon investigation the gdc.exe process was still running fine.  The GDC was displaying an error dialog related to the fglrun process triggering an exception.  The dialog was the typical “Program stopped at file filename.4gl, line number 999“.  Similarly support calls that describe “Genero Studio Crashing”, when the user started a program in Genero Studio, fglrun process triggering an exception and GDC displaying a “Program stopped at ….” dialog, Genero Studio was still running fine.

Takeaway for this article is to remind you that there are multiple processes in a Genero solution.  When reporting issues, make sure you identify correctly which process has the issue, and note if it really is a crash, or it is simply the case that an exception has been triggered.  Doing this can help triage the issue quickly without initially going down incorrect paths.