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