Re: [Gc] Allowing SIGINT during garbage collection may result in deadlock
ivmai at mail.ru
Mon Apr 19 23:22:55 PDT 2010
Mon, 19 Apr 2010 16:42:08 +0200 Burkhard Linke <blinke at cebitec.uni-bielefeld.de>:
> I've stumpled across a deadlock during execution of a mono application using a
> recent cvs checkout of bdwgc under Solaris 10/x86.
> All threads except the garbage collecting one are either suspended during
> stopping the world or correctly blocked by other means (IO, sleep for non GC
> threads etc).
> The garbage collecting thread was interrupted by SIGINT, which is unblocked in
> GC_remove_allowed_signals(). The deadlock occurs during the fact that the
> mono signal handlers is invoked and attempts to allocate memory. Excerpt of
> the stacktrace of garbage collecting thread:
> fffffd7fff28506c GC_lock () + 38
> fffffd7fff27298b GC_core_gcj_malloc () + 113
> 0000000000595427 mono_method_call_message_new () + 47
> 00000000005ffadf sigint_handler () + df
> fffffd7ffef07386 __sighndlr () + 6
> fffffd7ffeefbc32 call_user_handler () + 252
> fffffd7ffeefbe4e sigacthandler (2, 0, fffffd7ff75ff3e0) + de
> --- called from signal handler with signal 2 (SIGINT) ---
> fffffd7fff2782b4 GC_push_next_marked_uncollectable () + 24
> fffffd7fff2837ea GC_gcj_malloc () + 28a // calls GC_lock
> Since the lock is already held by the very same thread GC_lock() blocks and
> results in a dead lock. The same problem may occur in any application that is
> allocating memory during the SIGINT handler (or one of the other unblocked
> signals' handler).
> I would propose blocking the signals during garbage collection, since allowing
> them may result in undefined behavior. Any comments on this?
Most GC functions are not re-entrant (e.g. which do locking), so if you call a GC function from an async signal, you should do signal blocking (deferring) in every non-reentrant GC API function (instead of doing it for garbage collections), right?
> Burkhard Linke
More information about the Gc