[Mono-bugs] [Bug 598049] New: Deadlocks due to invocation of async unsafe fucntions in signal handlers

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=598049

http://bugzilla.novell.com/show_bug.cgi?id=598049#c0


           Summary: Deadlocks due to invocation of async unsafe fucntions
                    in signal handlers
    Classification: Mono
           Product: Mono: Runtime
           Version: 2.6.x
          Platform: x86-64
        OS/Version: Solaris 10
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: misc
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: burkhard.linke at CeBiTec.Uni-Bielefeld.DE
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7)
Gecko/20091223 Firefox/3.5.2

Deadlocks may occur due to using async unsafe functions in signal handlers
(e.g. SIGINT). Signal handlers may only invoke functions marked as async safe.

Reproducible: Always

Steps to Reproduce:
1. Run a mono application using libgc
2. Send a SIGINT to the application during a garbage collection
Actual Results:  
Deadlock of the garbage collection thread.

Expected Results:  
Deferring the signal until garbage collection is finished

Deadlock occurs to due using GC_malloc() in the signal handler (or in one of
the functions the signal handler calls):

Stacktrace of the thread executing the garbage collection:

fffffd7ffef072f7 lwp_park (0, 0, 0)
 fffffd7ffeeffd08 mutex_lock_impl () + e8
 fffffd7ffeeffdfb mutex_lock () + b
 fffffd7fff28506c GC_lock () + 38
 fffffd7fff27298b GC_core_gcj_malloc () + 113
 fffffd7fff283785 GC_gcj_malloc () + 225
 00000000005900bf mono_object_new_alloc_specific () + 2f
 0000000000590878 mono_object_new_specific () + 88
 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
 fffffd7fff2765e1 GC_mark_some () + 1b5
 fffffd7fff26bab4 GC_stopped_mark () + a4
 fffffd7fff26b7c4 GC_try_to_collect_inner () + 138
 fffffd7fff26c93f GC_collect_or_expand () + c7
 fffffd7fff26cbc9 GC_allocobj () + f9
 fffffd7fff274492 GC_generic_malloc_inner () + 17e
 fffffd7fff275707 GC_generic_malloc_many () + 277
 fffffd7fff2837ea GC_gcj_malloc () + 28a
 fffffd7ffe8129af ???????? ()
 ....

The problem is not only related to Solaris, but should also affect all other
UNIX-like operation systems.
A clean solution would require separation of signal interception and signal
handling, e.g. by putting information about the signal in a queue and post to a
semaphore. The semaphore in turn wakes up a special signal handling thread.
(afaik sem_post() is the _only_ function guaranteed to by thread safe in the
POSIX standard)

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.