Date: Tue, 26 Aug 2014 15:00:11 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 10 - mplayer issue Message-ID: <53FC145B.7060400@herveybayaustralia.com.au> In-Reply-To: <CAG7kECP_Kh7kRTv=wV3_wvtnk2QgkWU3=K_80Tw1ge=UUX6MZA@mail.gmail.com> References: <53F88676.3060702@herveybayaustralia.com.au> <CAG7kECPvxkeL1fiPk7UxMft1=PzvXkcRdtT5B1G7%2B5F6SsFuPw@mail.gmail.com> <53FA8715.5020202@herveybayaustralia.com.au> <CAG7kECP_Kh7kRTv=wV3_wvtnk2QgkWU3=K_80Tw1ge=UUX6MZA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/25/14 11:53, Elliot Robinson wrote: > 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. 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/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... 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53FC145B.7060400>