FreeBSD 10 - mplayer issue

Da Rock freebsd-questions at
Tue Aug 26 05:00:22 UTC 2014

On 08/25/14 11:53, Elliot Robinson wrote:
> On Sun, Aug 24, 2014 at 8:45 PM, Da Rock <
> freebsd-questions at> wrote:
>> Need mencoder unfortunately, but I may reconsider that. It has just been
>> easier for users with the ui and habit now to use mplayer tools for the job
>> until now.
> I can second Roland Smith's recommendation of ffmpeg as a mencoder
> replacement. The few things it doesn't do well can be replaced by piping
> YUV output from mplayer2/mpv to ffmpeg.
> Ok, still haven't got used to debug tools yet, so I may need some coaching.
>> I ran gdb mplayer and then run with args of a video; got nothing except LWP
>> <number>/mplayer
> This is due to mplayer (or something it calls) forking a new Light Weight
> Process (LWP, i.e. thread). You'd have to C-c and `info threads` to see the
> threads, then `thread <thread#>` to get any useful data.
Thanks for that tip - that will help in future issues :)

I knew about LWP's, but I didn't know enough about gdb to get that far. 
Got the same result as you could see, but obviously that won't work all 
the time...
>> Then I decided to get a bit tricky and attach to a running process
>> instead. This yielded better results, but no real info (to me anyway :) ):
> Attaching to program: /usr/local/bin/mplayer, process 92289
>> [New LWP 100131]
> Reading symbols from /lib/
>> [New Thread 813006800 (LWP 100131/mplayer)]
> ...truncated shared library loading...
>> [Switching to Thread 813006800 (LWP 100131/mplayer)]
>> 0x0000000000cdcde6 in _umtx_op_err ()
>> So then I ran backtrace:
>> #0  0x0000000000cdcde6 in _umtx_op_err ()
>> #1  0x0000000000cdf20f in rwlock_rdlock_common ()
>> #2  0x0000000809ee2d17 in g_type_register_fundamental ()
>>     from /usr/local/lib/
>> #3  0x0000000809ee3a2a in g_type_register_static ()
>>     from /usr/local/lib/
>> #4  0x0000000809ee9b32 in g_type_plugin_get_type ()
>>     from /usr/local/lib/
>> #5  0x0000000809ee728c in g_type_init ()
>>     from /usr/local/lib/
>> #6  0x0000000809eee682 in g_strdup_value_contents ()
>>     from /usr/local/lib/
>> #7  0x0000000809ec4f76 in _init () from /usr/local/lib/
>> #8  0x00007fffffffcfc0 in ?? ()
>> #9  0x0000000801382691 in r_debug_state () from /libexec/
>> #10 0x0000000801381d27 in __tls_get_addr () from /libexec/
>> #11 0x0000000801380089 in .text () from /libexec/
>> #12 0x0000000000000000 in ?? ()
>> So how does this help? What can I do now?
>> I see a problem in what looks to be a register of sorts, but that would be
>> in gtk. I tried using -nogui and still got the same.
>> It should be noted that there should be a print out of version and other
>> info prior to display, and none of that is showing at all; so we're not
>> even getting that far. I also rebuilt it with debug in the options.
>> Cheers
> Nice call on the thread attach. No idea what's causing this to happen, but
> it's definitely thread related (rwlock_rdlock_common is the worker for a
> pthread function on read-write locks) and it's definitely in glib (
> is one of the big glib dynamic libs, _init is the setup
> function called by the dynamic linker). I'm still going with "deadlock" in
> a on this one.
> I'd try an update/reinstall of glib before anything else. You shouldn't
> have deadlocks when initializing a shared library. I'm pretty sure this
> wasn't the only thread, so it might be interesting to see the output of
> `info threads` and a backtrace from any threads (if you feel compelled to
> debug this any more and the glib reinstall doesn't help). I'd offer to take
> a look myself, but I don't have a running system at the moment due to a bug
> in the ZFS bootloader...
I'm running a rebuild of glib (both old and new) now, but I did the 
debug prior. There was only one thread as it turned out; when I ran info 
threads it just gave '* 2 Thread 813006800 (LWP 101101/mplayer) 
0x0000000000cdcde6 in _umtx_op_err ()'. Running the bt gave the same 
output as posted previously.

The idea that it is running on a different library may be right - might 
not have got updated or could even be hitting the other glib (choice of 
2.36 or 1.12).

I guess we'll see how the rebuild goes...
> If rebuilding glib doesn't help and there are no more interesting threads,
> I'd file this as a bug. Not sure what against yet (kernel, pthread, glib,
> mplayer are all involved), but hopefully backtraces from other threads will
> make this less opaque. I'm just working off of general debugging knowledge
> at this point, so maybe someone with more pthread/kernel/glib/general
> FreeBSD knowledge than I would have more insight into this.
> Best of luck,
> Elliot Robinson
> PGP Key: 9FEDE59A
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list