[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