[Gc] GC_INIT? Threads?

[The Devils Jester]

The only output I get, aside from the stack trace is:
Collecting from unknown thread
Abort trap: 6

My application is organized as follows:

MAIN APP (does not use GC)
   GC_INIT()
   NEW THREAD
         CALL LIBRARY FUNCTION (library uses GC)

This crashes, while

MAIN APP (does not use GC)
   GC_INIT()
   CALL LIBRARY FUNCTION (library uses GC)

Works perfectly fine.

What am I doing wrong?  Do I have to initialize the GC in some special
fashion?


On Mon, Aug 19, 2013 at 11:35 PM, Bruce Hoult <bruce at hoult.org> wrote:

> That's not a crash, it's a deliberate abort because some sanity-checking
> code found that your world was insane. There are several things that can go
> wrong inside GC_push_all_stacks, so it would be helpful to have the
> message that GC_abort() printed.
>
> However, you should always call GC_INIT() from your main program, and as
> early as possible.
>
> On some versions and platforms GC_INIT() installs code that registers
> threads in a GC data structure because it's not possible to ask the OS for
> all your threads. If you call GC_INIT() from a new thread on those
> platforms then that thread will remain unregistered, which is one of the
> things that will make GC_push_all_stacks abort later.
>
>
>
> On Tue, Aug 20, 2013 at 4:10 PM, The Devils Jester <
> thedevilsjester at gmail.com> wrote:
>
>> I have a library that makes heavy use of of the GC, and it works quite
>> well when everything (the app, and the library) is in one thread.  I call
>> GC_INIT in the app, and all is well.
>>
>> If, however, the app creates a new thread that calls the library
>> function, then it crashes when the GC does its magic (below I have pasted
>> some relevant output).
>>
>> Is there some trick to using GC on a separate thread?  Do I call GC_INIT
>> from the main thread, or the one that calls the library functions?
>>
>>
>> 0   libsystem_kernel.dylib         0x00007fff8ad14212 __pthread_kill + 10
>> 1   libsystem_c.dylib             0x00007fff90d01b54 pthread_kill + 90
>> 2   libsystem_c.dylib             0x00007fff90d45dce abort + 143
>> 3   libgc.1.dylib                 0x000000010357676e GC_abort + 97
>> 4   libgc.1.dylib                 0x000000010357b413 GC_push_all_stacks
>> + 285
>> 5   libgc.1.dylib                 0x000000010357396e GC_mark_some + 377
>> 6   libgc.1.dylib                 0x000000010356d73e GC_stopped_mark +
>> 148
>> 7   libgc.1.dylib                 0x000000010356d645
>> GC_try_to_collect_inner + 245
>> 8   libgc.1.dylib                 0x000000010356e302
>> GC_collect_or_expand + 147
>> 9   libgc.1.dylib                 0x000000010356e51a GC_allocobj + 228
>> 10  libgc.1.dylib                 0x0000000103572515
>> GC_generic_malloc_inner + 249
>> 11  libgc.1.dylib                 0x00000001035725dd GC_generic_malloc +
>> 79
>> 12  libgc.1.dylib                 0x00000001035728c0 GC_core_malloc + 196
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>> is
>> believed to be clean.
>> _______________________________________________
>> Gc mailing list
>> Gc at linux.hpl.hp.com
>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130819/9ed93fdf/attachment.htm