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

[Sebastian Reitenbach]

On Monday, June 13, 2011 13:34 CEST, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote: 
 
>  
> On Monday, June 13, 2011 10:41 CEST, Richard Frith-Macdonald <rfm@gnu.org> 
> wrote: 
>  
> > 
> > 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.
> Ah, OK. When I continue Sudoku in gdb, it also goes on after the SIGSEV, 
> afterwards, it starts to hang again. When I then when it "hangs", press 
> Ctrl-C, and then look at the backtrace, it hangs again, at more or less the 
> same place in NSCountFrames();
> 
> 
> > 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.
> 
> I think I'm getting closer now, I added a lot of NSLogs(), and found that in 
> the jbuf_type struct bus and segv are always null, and I was wondering about 
> it. So started to compare manual pages of OpenBSD signal(3) and Linux 
> signal(2), and found, that they are indeed different:
> http://www.openbsd.org/cgi-bin/man.cgi?query=signal&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
> http://linux.die.net/man/2/signal

I just reread the Linux signal manual, and saw, its not retruning the address 
of the actual handler, but of the old handler, so  I exchanged the calls later 
in that function from i.e. signal(SIGSEGV, env->segv) to signal(SIGSEGV, 
SIG_DFL)
but without difference in the behaviour observed.

Sebastian


> 
> signal(3) on OpenBSD is a void function, but on Linux it returns 
> sighandler_t, so I changed it the code from:
>       env->segv = signal(SIGSEGV, recover);
>       env->bus = signal(SIGBUS, recover);
> to:
>       signal(SIGSEGV, recover);
>       signal(SIGBUS, recover);
>       env->segv = recover;
>       env->bus = recover;
> 
> Now, I see that those values are set, but it still hangs, see below the 
> output, where I added a couple of NSLog statements in NSDebug and NSException: