processes hanging in _umtx_op

Mel fbsd.questions at rachie.is-a-geek.net
Sun Oct 5 18:19:04 UTC 2008


On Sunday 05 October 2008 18:07:30 Dale Hagglund wrote:
> >>>>> "Mel" == Mel  <fbsd.questions at rachie.is-a-geek.net> writes:

>     Mel> It's not a 'standard answer', btw, but an educated guess, since
>     Mel> utmx is (simplified) the kernel equivalent of
>     Mel> pthread_(rwlock|mutex)_* and looks like it's hanging in one of
>     Mel> those functions.
>
> This was my guess as well.  I first noticed this hang while attempting
> to build gnuradio around the end of August.  During conversations with
> the maintainer, Diane Bruce, about this hang she recognized it from
> before and suggested that she'd been able to fix it at that time by
> upgrading all ports (or maybe just the wx port) on her system.
>
>     Mel> Now, it can simply be programmer error (lock twice, unlock
>     Mel> once), but most of the time the kernel catches this for me with
>     Mel> EDEADLK.
>
> The background with gnuradio and the Diane's suggestion to upgrade ports
> lead to my thought that I could easily have some sort of conflicting or
> out-of-date combination of libraries causing some sort of locking
> problem.

If upgrading ports is a possible solution, then you have the fine task of 
finding out, which library in everything that's being loaded is *NOT* linked 
with libthr, cause a likely candidate would be two different threading 
libraries being used.
I would start with ldd -a /path/to/python/wx.so and see if both libthr.so and 
libpthread.so (or maybe even libkse) show up.

Also inspect /etc/libmap.conf for entries you may have added in a not too 
recent past and forgot about.

Unfortunately, I see no obvious candidates in your package list (ie: 
compat-[456]x, *flash*).
-- 
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