Date: Sun, 24 Aug 2014 21:53:50 -0400 From: Elliot Robinson <elliot.robinson@argiopetech.com> To: Da Rock <freebsd-questions@herveybayaustralia.com.au>, "FreeBSD Questions !!!!" <freebsd-questions@freebsd.org> Subject: Re: FreeBSD 10 - mplayer issue Message-ID: <CAG7kECP_Kh7kRTv=wV3_wvtnk2QgkWU3=K_80Tw1ge=UUX6MZA@mail.gmail.com> In-Reply-To: <53FA8715.5020202@herveybayaustralia.com.au> References: <53F88676.3060702@herveybayaustralia.com.au> <CAG7kECPvxkeL1fiPk7UxMft1=PzvXkcRdtT5B1G7%2B5F6SsFuPw@mail.gmail.com> <53FA8715.5020202@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 24, 2014 at 8:45 PM, Da Rock < freebsd-questions@herveybayaustralia.com.au> 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. > 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/libncurses.so.8...done. > [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/libgobject-2.0.so.0 > #3 0x0000000809ee3a2a in g_type_register_static () > from /usr/local/lib/libgobject-2.0.so.0 > #4 0x0000000809ee9b32 in g_type_plugin_get_type () > from /usr/local/lib/libgobject-2.0.so.0 > #5 0x0000000809ee728c in g_type_init () > from /usr/local/lib/libgobject-2.0.so.0 > #6 0x0000000809eee682 in g_strdup_value_contents () > from /usr/local/lib/libgobject-2.0.so.0 > #7 0x0000000809ec4f76 in _init () from /usr/local/lib/libgobject-2.0.so.0 > #8 0x00007fffffffcfc0 in ?? () > #9 0x0000000801382691 in r_debug_state () from /libexec/ld-elf.so.1 > #10 0x0000000801381d27 in __tls_get_addr () from /libexec/ld-elf.so.1 > #11 0x0000000801380089 in .text () from /libexec/ld-elf.so.1 > #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 ( libgobject-2.0.so 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... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG7kECP_Kh7kRTv=wV3_wvtnk2QgkWU3=K_80Tw1ge=UUX6MZA>