Date: Wed, 11 Aug 2004 22:10:34 GMT From: Benedikt Meurer <benedikt.meurer@unix-ag.uni-siegen.de> To: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/69404: mono compiler (mcs) crashes with assertion failure in libpthread Message-ID: <200408112210.i7BMAYbY083362@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/69404; it has been noted by GNATS.
From: Benedikt Meurer <benedikt.meurer@unix-ag.uni-siegen.de>
To: freebsd-gnats-submit@FreeBSD.org, jhamby@anobject.com
Cc: Daniel Eischen <deischen@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408112210.i7BMAYbY083362>