Re: Problem with exception handling: WAS: no thread-safe +initialize in old gnustep runtime?

[Richard Frith-Macdonald]

On 12 Jun 2011, at 12:56, Sebastian Reitenbach wrote:

> 
> commenting out the line below in -[NSException raise], allows Sudoku to work 
> as expected, also Burn seems to behave fine.
> I've seen other programs hanging in NSCountFrames() before, but that were on 
> error cases, so making sure not running into an error, fixed the problem...
> While I was testing for the release of the latest stable versions of gnustep, 
> I ran the test suite. The -base testsuite did hang in a couple of places, 
> where Richard already suspected a problem with the Exception handling. I had 
> to kill the processes, to make the testuite go on. With the line commented 
> out, the testuite also runs successfully to the end.
> 
> 1609 Passed tests
>  13 Dashed hopes
>   1 Skipped set
> 
> All OK!
> 
> 
> - (void) raise
> {
>  if (_reserved == 0)
>    {
>      _reserved = NSZoneCalloc([self zone], 2, sizeof(id));
>    }
>  //_e_stack = [GSStackTrace new];
> 
> #if     defined(_NATIVE_OBJC_EXCEPTIONS)
>  @throw self;
> #else
> 
> I don't think that just commenting out this line is the right/best solution 
> to the problem, but I hope its enough information for someone with more 
> insight to have a better idea how to fix it. Fixing it the right way would be 
> great step forward for GNUstep on OpenBSD (:

OK ... what's happening here is we are generating a stack trace by using 
methods to work back up the stack ...
On some architectures (and in any system where the stack is messed up (eg by 
the ffcall library) this procedure can get to a point where it causes a signal 
(such as segmentation fault) ... this is normal/expected.  The fact that gdb 
stops at this point is NOT normally an indication of any error/problem.
The stack trace code therefore uses a signal handler to trap the signal and 
deal with it gracefully by stopping the construction of the stack trace at the 
point where it's hit a problem in the stack.  It seems this may not be working 
properly for you.

Now, this ties in with your problem with NSTask ... since the NSTask code also 
uses a signal handler to detect when a child process has terminated.  So a 
failure to detect child termination may well be due to some problem with signal 
handling.

So, my guess is that your BSD system is handling signals oddly ... the signal 
handler code in gnustep uses very old and well tested posix signal semantics 
but there are lots of newer or system dependent tweaks on signal handling.  
Maybe theres something we need to be doing special on your system to get signal 
handling to work as expected?  Or maybe there's some subtle bug in the signal 
handling which just doesn't show uyp on other systems.  Either way, it might be 
worth looking at that and seeing if writing/using some alternative BSD signal 
handling code would solve the issues.