Seg Fault

[Alastair Reid]

Leon:
>>> Segmentation fault

>> Probably a stack overflow which, unfortunately, causes Hugs to
>> segfault.

> I presume this is the C stack overflowing, right?  One possibility,
> albeit a very non-portable one, to catch SIGSEGV and make a good
> guess as to whether it was caused by a stack overflow or not.
> Generating a beter error message in this case might help eliminate a
> few bug reports...

On closer inspection, Hugs has some code to catch signals, print a
somewhat useful error message ('Unexpected signal') and returns to the
main loop.  The error message could try to narrow it down to what kind
of signal it was but, whatever we do, the message the Hugs code is
supposed to report clearly isn't the one Leon reported.

Is it possible that Hugs distributions routinely have the DONT_PANIC
option set in options.h (which would explain the error message
obtained)?

Here's what options.h has to say:

  /* In a plain Hugs system, most signals (SIGBUS, SIGTERM, etc) indicate
   * some kind of error in Hugs - or maybe a stack overflow.  Rather than
   * just crash, Hugs catches these errors and returns to the main loop.
   * It does this by calling a function "panic" which longjmp's back to the
   * main loop.
   * If you're developing a GreenCard library, this may not be the right
   * behaviour - it's better if Hugs leaves them for your debugger to
   * catch rather than trapping them and "panicing".
   */
  #define DONT_PANIC 0

Most people out there are not using a C debugger to debug Hugs or C
code they are calling from Hugs using the ffi so this ought to be
turned off by default and only turned on by the few brave and hardy
souls who indulge.

Or, is it possible that the signal raised by stack overflows is not
one of:

  SIGABRT SIGBUS SIGFPE SIGHUP SIGILL SIGQUIT SIGSEGV SIGTERM

which are the ones Hugs catches?

--
Alastair