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

[Richard Frith-Macdonald]

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.