[Gc] Could gc linux stop-world signals hang PAM?

Boehm, Hans hans.boehm at hp.com
Wed Sep 20 17:32:13 PDT 2006


Going through old mail ...

I think the problem here is that dlopen is being called directly, rather
than GC_dlopen.  GC_dlopen exists since dlopen may try to allocate while
holding a dynamic loader lock.  The GC tries to acquire the dynamic
loader lock so that it can find roots in dynamic libraries.

Unfortunately, the best workaround probably consists of linker games to
get pam to call the right thing.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Alec Orr
> Sent: Thursday, August 24, 2006 4:42 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Could gc linux stop-world signals hang PAM?
> 
> Good evening folks:
> 
> I was wondering if anyone had seen a deadlock like this 
> before using the PAM libraries with GC.
> 
> We use Boehm GC 6.7
> PAM PAM 0.74
> RH Linux 2.4.20-8 (GNU/Linux).
> 
> I have 2 threads that are GC enabled, one uses PAM (which is 
> dlopened). 
>   It seems that if a full world garbage collect is invoked a 
> very specific time in the PAM authentication `process, the 
> PAM thread hangs or SIGSEGV.  Here are the stack traces 
> (taken from gdb).
> 
> I am not ruling out heap corruption on my part, but wondered 
> if anyone else had seen this before.
> 
> Thank you,
> Alec Orr
> WBEM Solutions
> 
> 
> Thread using the PAM library - Garbage collector aware.
> 
> (gdb) thread 3
> [Switching to thread 3 (Thread 1078996032 (LWP 32049))]#0  
> 0xffffe002 in ?? ()
> (gdb) bt
> #0  0xffffe002 in ?? ()
> #1  0x400324cc in GC_suspend_handler_inner (
>      sig_arg=0x1e <Address 0x1e out of bounds>) at 
> pthread_stop_world.c:212
> #2  0x4003244d in GC_suspend_handler (sig=30) at 
> pthread_stop_world.c:148
> #3  <signal handler called>
> #4  0x4000c9c0 in _dl_debug_state_internal () from /lib/ld-linux.so.2
> #5  0x4000c39e in _dl_init_internal () from /lib/ld-linux.so.2
> #6  0x4210dfb2 in dl_open_worker () from /lib/tls/libc.so.6
> #7  0x4000c266 in _dl_catch_error_internal () from /lib/ld-linux.so.2
> #8  0x4210da49 in _dl_open () from /lib/tls/libc.so.6
> #9  0x40056f6b in dlopen_doit () from /lib/libdl.so.2 #10 
> 0x4000c266 in _dl_catch_error_internal () from /lib/ld-linux.so.2
> #11 0x40057316 in _dlerror_run () from /lib/libdl.so.2
> #12 0x40056f14 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
> #13 0x4015fc72 in _pam_init_handlers () from /lib/libpam.so.0
> #14 0x4015f0e1 in _pam_dispatch () from /lib/libpam.so.0
> #15 0x4015f4b6 in _pam_init_handlers () from /lib/libpam.so.0
> #16 0x4015e2e7 in pam_start () from /lib/libpam.so.0
> 
> 
> Thread making memory allocations - Garbage collector aware
> 
> #0  0xffffe002 in ?? ()
> #1  0x4002182a in GC_stopped_mark (stop_func=0) at alloc.c:495
> #2  0x400214fa in GC_try_to_collect_inner (
>      stop_func=0x400210a8 <GC_never_stop_func>) at alloc.c:378
> #3  0x40022358 in GC_collect_or_expand (needed_blocks=1, 
> ignore_off_page=0)
>      at alloc.c:1009
> #4  0x40022542 in GC_allocobj (sz=32, kind=1) at alloc.c:1087
> #5  0x40026fd6 in GC_generic_malloc_inner (lb=127, k=1) at 
> malloc.c:138
> #6  0x400270d3 in GC_generic_malloc (lb=127, k=1) at malloc.c:194
> #7  0x40027623 in GC_malloc (lb=127) at malloc.c:319
> #8  0x400232b5 in GC_debug_malloc (lb=108, s=0x400acf60 
> "src/apiext.c", 
> i=81)
>      at dbg_mlc.c:492
> #9  0x4009d9ff in int_allocMemory ()
> 
> 
> 



More information about the Gc mailing list