discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pl2link crashes randomly


From: David Chisnall
Subject: Re: pl2link crashes randomly
Date: Thu, 7 Apr 2011 12:43:33 +0100

On 7 Apr 2011, at 12:31, Sebastian Reitenbach wrote:

> To actually be able to compile gnustep-base on OpenBSD with llvm (patch is 
> not 
> needed with gcc) I have to apply the following patch, that David suggested:
> 
> --- Source/NSObject.m.orig      Sun Apr  3 10:53:10 2011
> +++ Source/NSObject.m   Mon Apr  4 17:16:24 2011
> @@ -945,7 +947,7 @@ objc_create_block_classes_as_subclasses_of(Class super
>       finalize_imp = class_getMethodImplementation(self, finalize_sel);
> #endif
> 
> -#if (defined(__FreeBSD__) || defined(__OpenBSD__)) && defined(__i386__)
> +#if defined(__FreeBSD__) && defined(__i386__)
>       // Manipulate the FPU to add the exception mask. (Fixes SIGFPE
>       // problems on *BSD)
>       // Note this only works on x86
> 
> While David was suggesting above patch, he also mentioned the SIGFPE that 
> might happen, but here I see in thread 4: sig=27


Note that I didn't say that this would fix things, just that it was worth 
testing whether it was actually (still) needed on OpenBSD.  The default 
behaviour for floating point exceptions should (I think) be to evaluate to some 
kind of NaN representation, rather than raise a signal.  It isn't on FreeBSD 
for some reason, but we now have a public interface for setting the behaviour, 
so we don't need the asm anymore (and, actually, it doesn't work on recent 
FreeBSD versions, because they keep undoing it on context switches based on 
what you set via the public function).

The point of this asm is to turn off FPU exceptions, so that the OS never sees 
them and they are not delivered as SIGFPE.  

The fact that you're getting SIGPROF is a bit weird, but this code should not 
have anything to do with it.  Did you accidentally link against a profiling 
library, or specify something like -pg when compiling?  A simple fix should be 
to just mask SIGPROF here, but I'm not sure why the signal is being raised at 
all.  Can you try setting a breakpoint on setitimer() and see if it's hit (and 
the first argument is 2)?  

David

-- Sent from my Difference Engine






reply via email to

[Prev in Thread] Current Thread [Next in Thread]