From owner-freebsd-questions@FreeBSD.ORG Tue Aug 26 05:00:22 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3175B978 for ; Tue, 26 Aug 2014 05:00:22 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6807A367C for ; Tue, 26 Aug 2014 05:00:20 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 98AA627372 for ; Tue, 26 Aug 2014 15:00:11 +1000 (EST) Message-ID: <53FC145B.7060400@herveybayaustralia.com.au> Date: Tue, 26 Aug 2014 15:00:11 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: FreeBSD 10 - mplayer issue References: <53F88676.3060702@herveybayaustralia.com.au> <53FA8715.5020202@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 05:00:22 -0000 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 >> /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 ` 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"