FW: [Gc] Hang on Red Hat Enterprise Linux?

Boehm, Hans hans.boehm at hp.com
Thu Apr 29 16:56:28 PDT 2004


[I'm forwarding a truncated message to the list.  It's otherwise
big enough to potentially cause problems on dial-up connections or
with mailbox size limits.  If someone else wants to see all the logs,
I'll be happy to forward.  I'm looking at them.  Thanks.]

Hans

-----Original Message-----
From: Kenneth C. Schalk [mailto:ken at xorian.net]
Sent: Tuesday, April 27, 2004 8:43 PM
To: Boehm, Hans
Cc: gc at napali.hpl.hp.com
Subject: RE: [Gc] Hang on Red Hat Enterprise Linux?


> If you can get stack traces out of gdb for all the threads after it
> hangs, and if the state is roughly repeatable, that might tell us
> something.  The parallel mark code uses pthread condition variables.
> It would be nice to know if it looks like we temporarily lose a
> notification there.
I spent some more time looking at this today.  It looks to me like the
problem is with mutex acquisition.
I'm attaching logs from gdb when I attached to a single run of gctest
that hung a total of 7 times and some notes I made after examining the
stack traces in these logs.
We did a full up2date run on this machine, and that had no effect on
this problem.  At this point I think I need to file a bug with RedHat.
--Ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-log.1
Type: application/octet-stream
Size: 8853 bytes
Desc: not available
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20040429/e44572dc/gdb-log.obj
-------------- next part --------------
1
  - threads 1 and 3 are part of the main test code, and are suspended
  (waiting for a restart signal in GC_suspend_handler)
  - thread 2 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018
  (which I believe may really be pthread_support.c:1542).
  - threads 4-7, 9, and 10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.
  - thread 8 is a mark thread blocked in pthread_mutex_lock below
  GC_acquire_mark_lock below GC_return_mark_stack.  My guess is that
  this is the thread that should be able to proceed.  Later in
  GC_return_mark_stack, it releases the mark lock and calls
  GC_notify_all_marker, which looks like it broadcasts the condition
  variable that 7 other threads are waiting on.
2
  - threads 1 and 2 are part of the main test code, and are suspended (waiting
  for a restart signal in GC_suspend_handler)
  - thread 3 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018.
  - threads 4, 6, and 8-10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.  It looks like 6 and 9 may have
  woken up and are trying to re-lock the mutex.
  - threads 5 and 7 are mark threads that are both blocked in
  pthread_mutex_lock below GC_acquire_mark_lock.  My guess is that one
  of them should be able to proceed.  Thread 5 is in
  GC_return_mark_stack.
3
  - thread 1 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018.
  - threads 2 and 3 are part of the main test code, and are suspended (waiting
  for a restart signal in GC_suspend_handler)
  - threads 4, 5, and 7-10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.
  - thread 6 is a mark thread blocked in pthread_mutex_lock below
  GC_acquire_mark_lock.  My guess is that this is the one that should
  be able to proceed.  This is also in GC_return_mark_stack.
4
  - thread 1 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_mutex_lock below
  GC_acquire_mark_lock below GC_return_mark_stack.
  - threads 2 and 3 are part of the main test code, and are suspended
  (waiting for a restart signal in GC_suspend_handler).
  - threads 4-10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.  It looks like 6 and 7 may have
  woken up and are trying to re-lock the mutex.
5
  - thread 1 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018.
  - threads 2 and 3 are part of the main test code, and are suspended
  (waiting for a restart signal in GC_suspend_handler)
  - threads 4-6, and 8-10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.
  - thread 7 is a mark thread blocked in pthread_mutex_lock below
  GC_acquire_mark_lock below GC_return_mark_stack.  My guess is that
  this is the one that should be able to proceed.
6
  - threads 1 and 3 are part of the main test code, and are suspended
  (waiting for a restart signal in GC_suspend_handler)
  - thread 2 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018.  It
  looks like it may have woken up and is trying to re-lock the mutex.
  - threads 4 and 6-10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.  It looks like 6 and 9 may have
  woken up and are trying to re-lock the mutex.
  - thread 5 is a mark thread blocked in pthread_mutex_lock below
  GC_acquire_mark_lock below GC_return_mark_stack.  My guess is that
  this is the one that should be able to proceed, although it may be
  competing with 2, 6, and 9 for the lock.
7
  - threads 1 and 3 are part of the main test code, and are suspended
  (waiting for a restart signal in GC_suspend_handler)
  - thread 2 is part of the main test code and is performing a garbage
  collection.  It is blocked in pthread_cond_wait at mark.c:1018.
  - threads 4-7, 9, and 10 are mark threads.  They're all blocked in
  pthread_cond_wait at mark.c:1018.  It looks like 5 and 9 may have
  woken up and are trying to re-lock the mutex.
  - thread 8 is a mark thread blocked in pthread_mutex_lock below
  GC_acquire_mark_lock below GC_return_mark_stack.  My guess is that
  this is the one that should be able to proceed, although it may be
  competing with 5 and 9 for the lock.


More information about the Gc mailing list