[Gc] GC 6.2 on Suse

Hans Boehm Hans.Boehm at hp.com
Tue May 11 22:13:18 PDT 2004


Given that it was working on RH8, you might try forcing the use of
linuxthreads if there is a way to do that on Suse 9.  I assume
you are getting NPTL threads by default?

In order to eliminate the malloc interception, you should configure
without --enable-redirect-malloc (or -DREDIRECT_MALLOC if you are using
the older Makefile.direct)

Another possible fix might be to redefine the LOCK and UNLOCK macros
to do nothing until the first thread is forked, or at least until
main has been started.  But that would require a collector change.

Hans

On Fri, 7 May 2004, Jim Marshall wrote:

> Hi Hans,
>   I don't fully follow what you are referring to in your response.
> Sorry. I imagine Alec might as he has been working with the GC code
> intimatly for several months and I've only been looking at it for 4 days ;)
>
> I also believe we need to use the malloc wraping in our main
> application, as we don't have control over some shared objects which may
> call malloc. However; if disabling the malloc wraping works we can look
> into solving that dilema a different way.
>
> Given the example program provided earlier, what would I need to change
> to (possibly) get this to work? Do I need to use different options to
> the configure script for GC?
>
>  Please keep in mind the example program works fine when run on Red Hat 8.0.
>
> Thank for all your time!
> -Jim
>
> Hans Boehm wrote:
>
> >Now you're running into a different known issue.  Malloc (& calloc)
> >redirection doesn't really work with threads.  That's on my list for
> >the next version.  The problem is that thread initialization code
> >calls malloc (or calloc) which calls the GC, which assumes that threads
> >are initialized.  Also even malloc is automatically redirected,
> >I believe that currently the pthread_ calls are not.  And if you're
> >going to include gc.h anyway (to get pthread redirection), you might
> >as well use macros to redirect malloc and friends.
> >
> >(This can probably be worked around at some cost by defining calloc
> >and malloc to be a wrapper that initially just calls the system
> >versions, and adjusting the definition of free correspondingly.
> >But if you don't absolutely need implicit malloc redirection, it's
> >much easier to turn it off and just call the GC_ routines directly.)
> >
> >Hans
> >
> >On Thu, 6 May 2004, Jim Marshall wrote:
> >
> >
> >
> >>Hi,
> >> Alec is away so I'm working on this in the meantime. When I add
> >>'-lpthread' compile options for the example application (sent in
> >>original email) the program crashes before it even gets to main, here is
> >>the gdb backtrace:
> >>
> >>#0  0x4006214f in __pthread_alt_lock () from /lib/i686/libpthread.so.0
> >>#1  0x4005efb7 in pthread_mutex_lock () from /lib/i686/libpthread.so.0
> >>#2  0x400357d7 in GC_lock () at pthread_support.c:1436
> >>#3  0x4002a4ee in GC_malloc (lb=1073990960) at malloc.c:292
> >>#4  0x4002a6d2 in calloc (n=1, lb=1073990976) at malloc.c:344
> >>#5  0x4000fdaa in _dl_tls_setup () from /lib/ld-linux.so.2
> >>#6  0x4005f778 in __pthread_initialize_minimal ()
> >>   from /lib/i686/libpthread.so.0
> >>#7  0x4005c276 in call_initialize_minimal () from /lib/i686/libpthread.so.0
> >>#8  0x4005bca3 in _init () from /lib/i686/libpthread.so.0
> >>#9  0x4000d75c in call_init () from /lib/ld-linux.so.2
> >>#10 0x4000d890 in _dl_init_internal () from /lib/ld-linux.so.2
> >>#11 0x40000c4d in _dl_start_user () from /lib/ld-linux.so.2
> >>
> >>-Jim
> >>
> >>p.s.
> >> I don't know if this plays into the problem or not, but this is a
> >>Athlon 64 machine (the Red Hat machines we use are 32bit athlons or
> >>Pentium 4's).
> >>Hans Boehm wrote:
> >>
> >>
> >>
> >>>Did you remember the -lpthread to link against libpthread?
> >>>
> >>>The GC library is not terribly robust against being told there are threads
> >>>and then getting the stub library.  That should probably be fixed eventually.
> >>>
> >>>If that's not the problem, the next step is to check whether GC_thr_init()
> >>>is getting called, and to make sure that it calls GC_new_thread with the
> >>>main thread as argument.
> >>>
> >>>Hans
> >>>
> >>>On Wed, 5 May 2004, Alec Orr wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Hello again folks,
> >>>>
> >>>>We seem to be having a problem with GC 6.2 on SuSe 9.0 (uname -a: Linux
> >>>>starfury 2.4.21-202-athlon #1 Fri Apr 2 21:22:14 UTC 2004 i686 athlon
> >>>>i386 GNU/Linux). We have been using GC 6.2 for a while on Red Hat 8.0
> >>>>for a while with little trouble, we recently tried to bring our
> >>>>application over to SuSe but when we run our program we get a
> >>>>segmentation fault in the GC_init_thread_local function (it's being
> >>>>passed a NULL parameter). We took the example application
> >>>>(http://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example.html) and
> >>>>tried that and it worked fine, but our application is multithreaded
> >>>>(well the primary thread is basically paused and the secondary thread is
> >>>>listening on a socket). So I made a small change to the sample app (see
> >>>>below) and I get the same segmentation fault. Here is the gdb backtrace:
> >>>>
> >>>>#0  GC_init_thread_local (p=0x0) at pthread_support.c:215
> >>>>#1  0x40034a5f in GC_init_parallel () at pthread_support.c:947
> >>>>#2  0x400355c0 in GC_pthread_create (new_thread=0xbffff4cc, attr=0xbffff4d0,
> >>>>   start_routine=0x1, arg=0x1) at pthread_support.c:1233
> >>>>#3  0x0804871b in main ()
> >>>>
> >>>>
> >>>>it appears that the GC_lookup_thread called on line 947 of
> >>>>pthread_support.c returns a NULL, which in turn causes
> >>>>GC_init_thread_local to segv.
> >>>>
> >>>>Has anyone else run into this problem, or have any thoughts on what
> >>>>maybe going on?
> >>>>
> >>>>Thank You.
> >>>>
> >>>>We are using gcc version 3.3.1 (SuSE Linux)
> >>>>
> >>>>Modified example Program (compile options cc -L/var/tmp/gc/lib -lgc -ldl
> >>>>-I /var/tmp/gc/include -D__REENTRANT -DGC_THREADS gctest.c ):
> >>>>#include "gc.h"
> >>>>#include <pthread.h>
> >>>>#include <assert.h>
> >>>>#include <stdio.h>
> >>>>
> >>>>void* start(void* data)
> >>>>{
> >>>>   return NULL;
> >>>>}
> >>>>
> >>>>int main(int argc, char** argv) {
> >>>>   pthread_attr_t thrdData;
> >>>>   pthread_t thrd;
> >>>>   int i;
> >>>>
> >>>>   GC_INIT();
> >>>>
> >>>>   pthread_attr_init(&thrdData);
> >>>>   pthread_attr_setdetachstate(&thrdData, PTHREAD_CREATE_DETACHED);
> >>>>   /* Commenting the next line out lets program run normally */
> >>>>   pthread_create(&thrd, &thrdData, start, NULL);
> >>>>
> >>>>
> >>>>   for (i = 0; i < 10000000; ++i)
> >>>>   {
> >>>>   int **p = (int **) GC_MALLOC(sizeof(int *));
> >>>>   int *q = (int *) GC_MALLOC_ATOMIC(sizeof(int));
> >>>>   assert(*p == 0);
> >>>>   *p = (int *) GC_REALLOC(q, 2 * sizeof(int));
> >>>>   if (i % 100000 == 0)
> >>>>       printf("Heap size = %d\n", GC_get_heap_size());
> >>>>   }
> >>>>   return 0;
> >>>>}
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Gc mailing list
> >>>>Gc at linux.hpl.hp.com
> >>>>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> >
>
>


More information about the Gc mailing list