Date: Sun, 5 Oct 2008 15:46:27 +0200 From: Mel <fbsd.questions@rachie.is-a-geek.net> To: freebsd-questions@freebsd.org Cc: Dale Hagglund <dale.hagglund@gmail.com> Subject: Re: processes hanging in _umtx_op Message-ID: <200810051546.28440.fbsd.questions@rachie.is-a-geek.net> In-Reply-To: <86r66v6gsj.fsf@ponoka.ab.hsia.telus.net> References: <86r66v6gsj.fsf@ponoka.ab.hsia.telus.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 05 October 2008 02:12:44 Dale Hagglund wrote:
> I can reproduce this reliably with
>
> $ python -c "import wx"
>
> I'm running 7.0-RELEASE-p2 with "uname -a" giving the following output,
> suitably wrapped.
>
> FreeBSD ponoka.ab.hsia.telus.net
> 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2
> #0: Wed Jun 18 07:33:20 UTC 2008
> root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> i386
[...]
> Dale Hagglund
>
> ------------------------- start: kdump output -------------------------
> 34453 python 1223164746.661828 CALL munmap(0x2aa00000,0xc1000)
> 34453 python 1223164746.661840 RET munmap 0
> 34453 python 1223164746.662541 CALL
> _umtx_op(0x283071e0,0x8,0x1,0x283071c0,0 )
Can you change scheduler to ULE and rebuild kernel? Or better yet, try
7.1-PRERELEASE, since it's good to know if this bug persists with 7.1 being
close to release.
It's not a 'standard answer', btw, but an educated guess, since utmx is
(simplified) the kernel equivalent of pthread_(rwlock|mutex)_* and looks like
it's hanging in one of those functions.
If you're comfy with kernel debugging, print uap->op when it's hanging, so we
know which op it's waiting on.
Now, it can simply be programmer error (lock twice, unlock once), but most of
the time the kernel catches this for me with EDEADLK.
--
Mel
Problem with today's modular software: they start with the modules
and never get to the software part.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200810051546.28440.fbsd.questions>