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

[Richard Frith-Macdonald]

On 14 Jun 2011, at 09:47, Richard Frith-Macdonald wrote:

> 
> On 14 Jun 2011, at 09:38, David Chisnall wrote:
> 
>> Which compiler / flags are you using?  The ability to generate a backtrace 
>> is HIGHLY dependent on the compiler.  For example, -fomit-frame-pointer 
>> (default at some optimisation levels) will break it.  There are also some 
>> linker flags required for undwind-based backtraces to work.
> 
> I believe gnustep-make copes with that ... certainly it specifically disables 
> omitting the frame pointer, so that should not be an issue.
> 
> It's worth noting that *NO* stack trace code will work correctly if the stack 
> is corrupted ... so it's quite possible that Seabastian may be seeing memory 
> corruption from somewhere else rather than a stacktrace bug (and such memory 
> corruption would be likely to behave differently from system to system). 
> 
> My feeling is that first priority ought to be to figure out why the signal 
> handling code is not working ... I know it can't be 100% reliable (after all 
> signal handling is not really thread safe), but it ought to be catching any 
> problem in the stack trace normally, and recovering.  Writing an alternative 
> signal handling implementation using the latest BSD APIs rather than the 
> original signal() system call, would seem to make sense here.

Incidentally, thanks to your push to re-implement locking and *require* posix 
threads in GNUstep, we ought now be able to depend upon the availability of 
pthread_sigmask() etc to support thread-safe signal handling ... so rewriting 
signal handling that way would be good.
If I ever find some time I will try doing that.