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

[Sebastian Reitenbach]

On Monday, June 13, 2011 16:41 CEST, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote: 
 
> 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.

After bothering ports@openbsd with the crasher I've seen in libexecinfo, I was 
told, that this library seems to be kind of broken in general. I was also 
pointed to libbacktrace: 
http://opensource.conformal.com/cgi-bin/cvsweb/backtrace/backtrace/
Which I installed, and linked gnustep-base against it. It actually fails the 
same way like libexecinfo fails. Looking at the code, it is more or less doing 
the same like libexecinfo. 
I also tried to run Sudoku without HAVE_BACKTRACE on Linux. After ./configure I 
edited the config.h and change the #define HAVE_BACKTRACE 1 into a #undef 
HAVE_BACKTRACE. Now gnustep-base was using the gnustep internal backtrace 
generation, which just worked as expected.
If I don't find a solution to the problem, I think, I kind of have to assume 
that the backtrace generation is not working on OpenBSD, and will just disable 
the generation of the backtrace, with the little patch I had. 

cheers,
Sebastian