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

[Sebastian Reitenbach]

Hi,
 
On Monday, June 13, 2011 14:30 CEST, David Chisnall <theraven@sucs.org> wrote: 
 
> On 13 Jun 2011, at 13:19, Sebastian Reitenbach wrote:
> 
> > 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.
> 
> 
> This will break any code that had already set a signal handler (for example, 
> anything using GC, since libgc implements dirty bits for its generational 
> garbage collection by marking pages as no-access and then catching the 
> SIGSEGV).  A better solution would be to stop using the C signal() function 
> and use the POSIX sigaction() function.  Since this has been in the standard 
> since 1990, I'd imagine that it's pretty well supported, although someone 
> should check MinGW.  
> 
> Even with that change, this code isn't even remotely thread safe, so it would 
> be better to replace it with something less fragile.  Is there no port of 
> libexecinfo to OpenBSD?  If there is, then it would be a good idea to add 
> that as a dependency for the FreeBSD port and use the backtrace() version.

Thanks for pointing me to libexecinfo, I wasn't aware of it. There exists a 
port for it for OpenBSD, and I got gnustep-base configure to find and link 
against it. (I had to use LDFLAGS=-lexecinfo) in the configure and make 
environment.
Unfortunately, Sudoku now crashes in libexecinfo ;)
I really ugly hacked libexecinfo, to not to crash, and then Sudoku was able to 
successfully generate the sudoku.

Libexecinfo, when the crasher there is investigated and fixed, could be a way 
to go, but still doesn't explain the hanger, when its not used.

cheers,
Sebastian




> 
> David
> 
> -- Sent from my brain
>