processes hanging in _umtx_op
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
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:
Problem with today's modular software: they start with the modules
and never get to the software part.
More information about the freebsd-questions