Re: [Gc] Allowing SIGINT during garbage collection may result in deadlock

Ivan Maidanski 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>:

> Hi,
> 
> 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?

> 
> Regards,
> Burkhard Linke



More information about the Gc mailing list