[Gc] Collection from unknown thread with iOS simulator

Discussion:

Joa Ebert

2013-03-12 17:10:46 UTC

Hi,

I am running into some issues with the iPhone simulator when using the GC
7.2 and 7.2d. Basically the issue is that I get a "Collecting from unknown
thread" error.

First of all the GC is configured with

CFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
CPPFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
LDFLAGS="-arch i386 -isysroot $SDK_LIB -Wl,-syslibroot $SDK_LIB"

./configure --disable-dependency-tracking --host=arm-apple-darwin
--enable-cplusplus --enable-static --disable-shared
--enable-thread-local-alloc --enable-parallel-mark
--enable-threads=pthreads --prefix=/Users/joa/Development/libgc

I am also running into the issue when I specify --enable-threads=posix.
This is how I include the header files:

#define GC_THREADS
#define GC_NOT_DLL
#define GC_OPERATOR_NEW_ARRAY

#include <gc/gc.h>
#include <gc/gc_cpp.h>

When the program starts I do call GC_INIT(). So from this perspective
everything should be fine. But unfortunately the simulator spawns a thread
that is not tracked by the GC causing this error.

I have tried several solutions like GC_use_threads_discovery before GC_INIT
without success. This ends in SIGABRT with "Darwin task-threads-based stop
and push unsupported".

The operating system is Mac OS X 10.6 and the simulator uses SDK version
4.3 in case that matters for you.

This is the trace of the offending thread as it seems:

#0 0x90aa20ee in __semwait_signal_nocancel ()
#1 0x90aa1fd2 in nanosleep$NOCANCEL$UNIX2003 ()
#2 0x90b1cfb2 in usleep$NOCANCEL$UNIX2003 ()
#3 0x90b3e6f0 in abort ()
#4 0x00268f64 in GC_abort ()
#5 0x0026f9ee in GC_push_all_stacks ()
#6 0x0026a78b in GC_default_push_other_roots ()
#7 0x002678c9 in GC_push_roots ()
#8 0x00263d32 in GC_mark_some ()
#9 0x0025990a in GC_stopped_mark ()
#10 0x00259726 in GC_try_to_collect_inner ()
#11 0x0025ac48 in GC_collect_or_expand ()
#12 0x00261351 in GC_alloc_large ()
#13 0x00261896 in GC_generic_malloc ()
#14 0x00261e2e in GC_malloc_uncollectable ()
[...]
#25 0x90a62259 in _pthread_start ()
#26 0x90a620de in thread_start ()

I remember that I already had the collector working on an actual device a
while ago so I am a little bit confused about what is going on here.
Any help is greatly appreciated!

Best,

Joa

Joa Ebert

2013-03-12 20:03:20 UTC

Permalink

Bruce Hoult

2013-03-12 22:59:43 UTC

Permalink

You're probably going to need to call GC_register_my_thread() at the
start of each of your threads (or at in any that can make GC
allocation calls).

Post by Joa Ebert
Hi,
I am running into some issues with the iPhone simulator when using the GC
7.2 and 7.2d. Basically the issue is that I get a "Collecting from unknown
thread" error.
First of all the GC is configured with
CFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
CPPFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
LDFLAGS="-arch i386 -isysroot $SDK_LIB -Wl,-syslibroot $SDK_LIB"
./configure --disable-dependency-tracking --host=arm-apple-darwin
--enable-cplusplus --enable-static --disable-shared
--enable-thread-local-alloc --enable-parallel-mark --enable-threads=pthreads
--prefix=/Users/joa/Development/libgc
I am also running into the issue when I specify --enable-threads=posix.
#define GC_THREADS
#define GC_NOT_DLL
#define GC_OPERATOR_NEW_ARRAY
#include <gc/gc.h>
#include <gc/gc_cpp.h>
When the program starts I do call GC_INIT(). So from this perspective
everything should be fine. But unfortunately the simulator spawns a thread
that is not tracked by the GC causing this error.
I have tried several solutions like GC_use_threads_discovery before GC_INIT
without success. This ends in SIGABRT with "Darwin task-threads-based stop
and push unsupported".
The operating system is Mac OS X 10.6 and the simulator uses SDK version 4.3
in case that matters for you.
#0 0x90aa20ee in __semwait_signal_nocancel ()
#1 0x90aa1fd2 in nanosleep$NOCANCEL$UNIX2003 ()
#2 0x90b1cfb2 in usleep$NOCANCEL$UNIX2003 ()
#3 0x90b3e6f0 in abort ()
#4 0x00268f64 in GC_abort ()
#5 0x0026f9ee in GC_push_all_stacks ()
#6 0x0026a78b in GC_default_push_other_roots ()
#7 0x002678c9 in GC_push_roots ()
#8 0x00263d32 in GC_mark_some ()
#9 0x0025990a in GC_stopped_mark ()
#10 0x00259726 in GC_try_to_collect_inner ()
#11 0x0025ac48 in GC_collect_or_expand ()
#12 0x00261351 in GC_alloc_large ()
#13 0x00261896 in GC_generic_malloc ()
#14 0x00261e2e in GC_malloc_uncollectable ()
[...]
#25 0x90a62259 in _pthread_start ()
#26 0x90a620de in thread_start ()
I remember that I already had the collector working on an actual device a
while ago so I am a little bit confused about what is going on here.
Any help is greatly appreciated!
Best,
Joa
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Ivan Maidanski

2013-03-15 20:59:39 UTC

Permalink

Hi Joa,

At least in gc7.3, there are 4 ways of app threads registering on Darwin/iOS:
* explicitly by calling GC_register_my_thread (called from a callback passed to GC_call_with_stack_base)
* explicitly by calling GC_pthread_create instead of each pthread_create
* implicitly by redirecting pthread_create to GC_pthread_create (for this, your app should include gc.h in each module that calls pthread_create)
* implicitly all threads of app are registered (scanned) if GC_use_threads_discovery is called before GC_INIT (or if GC is compiled with -D GC_DISCOVER_TASK_THREADS having DARWIN_DONT_PARSE_STACK undefined).

It seems that you:
* do not use any of the way listed above;
*Â had a positive experience with an old GC for which GC_use_threads_discovery was on by default. Now, this method is deprecated (to prevent suspending threads that do not deal with GC-related pointers). To get old-style behavior, use GC_DISCOVER_TASK_THREADS.

Regards,
Ivan

Post by Bruce Hoult
You're probably going to need to call GC_register_my_thread() at the
start of each of your threads (or at in any that can make GC
allocation calls).