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

[David Chisnall]

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.

David

On 14 Jun 2011, at 09:31, Sebastian Reitenbach wrote:

> 
> 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
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


-- Sent from my PDP-11