processes hanging in _umtx_op
Mel
fbsd.questions at rachie.is-a-geek.net
Sun Oct 5 13:46:31 UTC 2008
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 at 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.
More information about the freebsd-questions
mailing list