Date: Sat, 30 Aug 2014 15:30:41 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 10 - mplayer issue Message-ID: <54016181.9020901@herveybayaustralia.com.au> In-Reply-To: <53FC145B.7060400@herveybayaustralia.com.au> 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> <53FC145B.7060400@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/26/14 15:00, Da Rock wrote: > 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... Well that was a complete no go - I've rebuilt everything and it still has the same issue. Worse, chrome is crashing the whole system... I'm starting to think there is some serious problems with 10 at this stage. All my 9's are still fine so far :) >> >> 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" > > _______________________________________________ > 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?54016181.9020901>