[Gc] some more info on previously mentioned hangups

Boehm, Hans hans.boehm at hp.com
Wed Aug 31 13:27:23 PDT 2005

You might try wrapping the calls in GC_do_blocking, assuming the
vsyslog calls themselves do not change any pointers to the
garbage-collected heap.

This unfortunately requires GC7.  The similar GC6.5 facility is
known to be flakey.  And this currently only works with pthreads.

Another alternative may be just to block the signals used to suspend
threads during the vsyslog calls.  That will effectively cause a
thread initiating GC to wait for the vsyslog to complete, which
is a bit suboptimal.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Travis Griggs
> Sent: Wednesday, August 31, 2005 10:18 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] some more info on previously mentioned hangups
> A week or so ago, I was asking some questions, based on the fact that 
> we were seeing thread lockups. We run a number of different levels of 
> real time (and some not real time too) thread priorities.
> We think we've found a part of the problem: vsyslog(). We use this a 
> bunch in our system. We current have a system we can deadlock in a 
> matter of minutes. If we comment out (i.e. noop) the syslog 
> calls, then 
> everything works great. Why am I posting this on the libgc list?
> One thing that the sparse documentation about vsyslog alludes to is 
> that it is not signal safe. We don't actually have any signal 
> handling 
> code in our system, but we've looked at the libgc source... 
> and we know 
> it does :) We've tried with both the debian libgc (6.4 I 
> think?) and a 
> stock build of the 7 of alpha 4 (which I assume still uses signals to 
> do the stop_world (will go check in a second)) and both exhibit the 
> problem.
> I'm wondering if others more familiar either signals, async unsafe 
> code, the libgc stop mechanism, might see a potential deadlock 
> situation here.
> --
> Travis Griggs
> Objologist
> "It had better be a pretty good meeting, to be better than no 
> meeting at all" -- Boyd K Packer
> -----------------------------------------
> DISCLAIMER: This email is bound by the terms and conditions 
> described at https://www.key.net/disclaimer.htm
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list