[Gc] Re: Boehm GC + Thread Building Blocks
alexander.herz at mytum.de
Mon Jul 2 00:43:45 PDT 2012
On 06/29/2012 10:01 PM, Boehm, Hans wrote:
> Are you sure that you're really getting the worker threads registered, and not just getting lucky and always triggering the GC from the main thread, or a separately registered thread?
> I don't think there's currently a debugging routine that dumps the registered threads. There probably should be. There are many routines in pthread_support.c that walk the thread table, and could be easily imitated to build such a routine; GC_mark_thread_local_free_lists() is a simple example.
> Stack overflows are likely to be an issue, if you use the common approach of catching a SIGSEGV on an alternate stack. The GC doesn't know about the alternate stack. The best solution is probably to disable collection while on the alternate stack, and to arrange for GC-generated signals to be held while in the handler. That way the GC should never catch a thread on the alternate stack.
>> -----Original Message-----
>> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
>> On Behalf Of aherz
>> Sent: Friday, June 29, 2012 2:13 AM
>> To: gc at linux.hpl.hp.com
>> Subject: Re: [Gc] Re: Boehm GC + Thread Building Blocks
>> Ivan Maidanski <ivmai at ...> writes:
>>> Hi Alexander,
>>> What's your target?
>>> Have you explicitly initialize GC and register threads?
>>> Tue, 26 Jun 2012 12:47:16 +0000 (UTC) от aherz <alexander.herz <at>
>>>> hm..I'm now getting some strange, possibly related problems:
>>>> Mostly, the ap terminates without any problems. Sometimes,
>>>> in one of the tbb worker threads, a SIGPWR
>>>> (wiki says this might be used by boehm gc)
>>>> is received and afterwards I get a "Collection in unknown thread"
>>>> Maybe tbb's signal handling is interfering with boehm's?
>>>> Btw: I also get an "Collection in unknown thread" when a stack
>> overflow is
>>>> Gc mailing list
>>>> Gc at ...
>> Hi Ivan,
>> my target is a 64bit ubuntu (10.04). I compile the tbb library from
>> source and
>> added the #define GC_THREADS and #include <gc_cpp.h> to the library.
>> The garbage collector does work (mostly when I run the application with
>> gc debug
>> output, I can see that collections happen, so the threads are
>> registered). So
>> mostly things work ok, only in rare circumstances something goes wrong.
>> I don't
>> think that the problem is the registration of the threads.
>> I think the problem is that tbb implements its own exception handling
>> and that
>> might interfere with boehm gc's signals.
>> Is there an easy way to make boehm gc dump which threads have been
>> registered to
>> verify that this is not the problem?
>> Gc mailing list
>> Gc at linux.hpl.hp.com
> Gc mailing list
> Gc at linux.hpl.hp.com
I figured out how to get a dump of the registered threads, one can
simple export CFLAGS=-DDEBUG_THREADS
before running configure on bdwgc. That will make the gc output all
sorts of info regarding threads.
As for my problem itself, it turned out that another version of the
bdwgc and the tbb shared lib was present on my system (and was used
instead of the version I intended to use). This caused all sorts of
havok. So the threads were indeed not registered and I was lucky hitting
the main thread most of the time. Now things appear to be fine.
More information about the Gc