[Gc]: GC 7.2e: crash in threadkey_test under FreeBSD

Boehm, Hans hans.boehm at hp.com
Fri Nov 22 11:37:51 PST 2013

Without digging deeply, the connection between that and THREAD_LOCAL_ALLOC seems tenuous.  Based on the bug report, it sounds like the zero signal is redundant?  Would it make sense just to ignore it and return from the handler on FreeBSD?  Doing so only partially removes an internal consistency check.


> -----Original Message-----
> From: Vitaly Magerya [mailto:vmagerya at gmail.com]
> Sent: Friday, November 22, 2013 4:10 AM
> To: Boehm, Hans; Ivan Maidanski
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc]: GC 7.2e: crash in threadkey_test under FreeBSD
> On 2013-11-21 02:42, Boehm, Hans wrote:
> > I would look at the info and context arguments, and see if
> > it's possible to determine anything else about this signal.  If
> > things are as they appear, this seems like a kernel bug.  As far
> > as I can tell, if a signal handler is invoked, the first argument
> > is required to be one of the signals for which the handler was
> > registered; zero is not allowed by Posix.  My guess is either:
> >
> > a) The stack trace is incorrect, or
> > b) This signal was generated at a particularly inopportune
> >    time, for the kernel or libc, and the handler did not get
> >    invoked correctly due to a FreeBSD bug.
> You're right, this did in fact turned out to be a FreeBSD bug.
> A solution has been already been developed [1], and it'll probably
> make it's way into the upcoming releases at some later date.
> For the time being, should be disable THREAD_LOCAL_ALLOC on
> FreeBSD? That will fix the test case, but while the underlying
> problem with deferred signals is still present, I don't know if
> it'll just manifest itself in another way.
> [1] https://lists.freebsd.org/pipermail/freebsd-hackers/2013-
> November/043837.html

More information about the Gc mailing list