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