ports/69404: mono compiler (mcs) crashes with assertion failure in libpthread

Wed Aug 11 22:10:35 UTC 2004

The following reply was made to PR ports/69404; it has been noted by GNATS.

From: Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de>
To: freebsd-gnats-submit at FreeBSD.org, jhamby at anobject.com
Cc: Daniel Eischen <deischen at freebsd.org>
Subject: Re: ports/69404: mono compiler (mcs) crashes with assertion failure
 in libpthread
Date: Thu, 12 Aug 2004 00:08:21 +0200

 (I CC'ed Daniel Eischen, who's listed as the author of the lock.*)

 Looking deeper into the problem, heres the backtrace from the mcs crash 
 (with the assertion as mentioned above):

 #0  0x2839fa73 in kse_thr_interrupt () at kse_thr_interrupt.S:2
 #1  0x2839020b in _thr_sig_add (pthread=0x810de00, sig=6, info=0x0)
      at /usr/src/lib/libpthread/thread/thr_sig.c:998
 #2  0x283906ef in _thr_sig_send (pthread=0x810de00, sig=6)
      at /usr/src/lib/libpthread/thread/thr_sig.c:1149
 #3  0x2838a155 in _pthread_kill (pthread=0x810de00, sig=6)
      at /usr/src/lib/libpthread/thread/thr_kill.c:60
 #4  0x28389a97 in _raise (sig=6)
      at /usr/src/lib/libpthread/thread/thr_raise.c:46
 #5  0x2847ed62 in abort () from /lib/libc.so.5
 #6  0x2845770f in __assert () from /lib/libc.so.5
 #7  0x283a09e2 in _lock_acquire (lck=0xbf8ec52c, lu=0xbf8ec534, prio=382)
      at /usr/src/lib/libpthread/sys/lock.c:171
 #8  0x28393913 in mutex_lock_common (curthread=0x810de00, m=0x284af434,
      abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:495
 #9  0x28394e81 in __pthread_mutex_lock (m=0x284af434)
      at /usr/src/lib/libpthread/thread/thr_mutex.c:796
 #10 0x2818b1ee in WaitForSingleObjectEx (handle=0xe, timeout=500, 
 alertable=0)
      at handles-private.h:97
 #11 0x281831fb in CreateProcess (appname=0xd, cmdline=0x80f3a5c,
      process_attrs=0x0, thread_attrs=0x0, inherit_handles=382,
      create_flags=382, new_environ=0x0, cwd=0x0, startup=0xbf8ec79c,
      process_info=0xbf8ec78c) at processes.c:427
 #12 0x2815119e in ves_icall_System_Diagnostics_Process_Start_internal (
      appname=0x80f2a00, cmd=0x80f3a50, dirname=0x808df30, 
 stdin_handle=0x17e,
      stdout_handle=0x17e, stderr_handle=0x17e, process_info=0xbf8ec974)
      at process.c:870

 (gdb) frame 7
 #7  0x283a09e2 in _lock_acquire (lck=0xbf8ec52c, lu=0xbf8ec534, prio=382)
      at /usr/src/lib/libpthread/sys/lock.c:171
 171                     LCK_ASSERT(lu->lu_myreq->lr_owner == lu);
 Current language:  auto; currently c
 (gdb) print *lck
 $26 = {l_head = 0x1, l_tail = 0x28071800, l_type = 4294967263,
    l_wait = 0xffffffff, l_wakeup = 0xffffffff}

 (gdb) frame 8
 #8  0x28393913 in mutex_lock_common (curthread=0x810de00, m=0x284af434,
      abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:495
 495                     THR_LOCK_ACQUIRE(curthread, &(*m)->m_lock);
 (gdb) print m
 $18 = (pthread_mutex_t *) 0x284af434
 (gdb) print &(*m)->m_lock
 $29 = (struct lock *) 0x805dc00
 (gdb) print *(*m)
 $22 = {m_lock = {l_head = 0x7273752f, l_tail = 0x636f6c2f,
      l_type = 1815047265, l_wait = 0x6d2f6269, l_wakeup = 0x726f6373},
    m_type = 778201452, m_protocol = 2087480420, m_queue = {
      tqh_first = 0x74737953, tqh_last = 0x522e6d65}, m_owner = 0x69746e75,
    m_flags = 1395549549, m_count = 1634300517, m_refcount = 1635412332,
    m_prio = 1852795252, m_saved_prio = 1699957038, m_qe = {
      tqe_next = 0x6c616972, tqe_prev = 0x62617a69}}

 Looks like memory corruption to me.

 I just restarted with kern.smp.disabled=1 and now I get different crashes:

 a) The well known:
 Assertion failed: (lu->lu_myreq->lr_owner == lu), function 
 _lock_acquire, file /usr/src/lib/libpthread/sys/lock.c, line 171.
 zsh: abort (core dumped)  mcs test.c -pkg:gtk-sharp

 b) And the newcomer:
 zsh: segmentation fault (core dumped)  mcs test.c -pkg:gtk-sharp

 And here comes the backtrace of the latter:

 (gdb) thread 1
 [Switching to thread 1 (process 100151)]#0  0x2839fa73 in 
 kse_thr_interrupt ()
      at kse_thr_interrupt.S:2
 2       RSYSCALL(kse_thr_interrupt)
 (gdb) bt
 #0  0x2839fa73 in kse_thr_interrupt () at kse_thr_interrupt.S:2
 #1  0x283995dc in kse_check_completed (kse=0x804d000)
      at /usr/src/lib/libpthread/thread/thr_kern.c:1518
 #2  0x28397e6e in kse_sched_multi (kmbx=0x17e)
      at /usr/src/lib/libpthread/thread/thr_kern.c:979
 #3  0x0810d000 in ?? ()
 (gdb) thread 2
 [Switching to thread 2 (process 100143)]#0  0x2839fa53 in kse_release ()
      at kse_release.S:2
 2       RSYSCALL(kse_release)
 (gdb) bt
 #0  0x2839fa53 in kse_release () at kse_release.S:2
 #1  0x2838e4ba in sig_daemon (arg=0x0)
      at /usr/src/lib/libpthread/thread/thr_sig.c:216
 #2  0x28397d3f in kse_sched_single (kmbx=0x17f)
      at /usr/src/lib/libpthread/thread/thr_kern.c:895
 #3  0x00000000 in ?? ()

 Playing around with mono trying to crash it, I found the following 
 program to be a good starting point:

 using Gtk;
 using System;

 class Test : Gtk.Bin
 {
    public static void Main ()
    {
      Application.Init ();
      Button btn = new Button ("Click me");
      btn.Clicked += new EventHandler (Clicked);
      btn.Show ();
      Window window = new Window ("Hello");
      window.Add (btn);
      window.Show ();
      Application.Run ();
    }

    static void Clicked (object o, EventArgs args)
    {
      Application.Quit ();
    }
 }

 Compiling with:

 mcs test.cs -pkg:gtk-sharp

 It sometimes crashes with

 zsh: segmentation fault (core dumped)  mcs test.cs -pkg:gtk-sharp

 but on the other hand the compilitation succeeds (after setting 
 GC_DONT_GC=True) from time to time. So I guess the gc trashes
 pthread data structures under certain conditions.

 HTH,
 Benedikt