GNOME Bugzilla – Bug 725870
Banshee hangs when connecting the Nexus 5
Last modified: 2014-03-15 15:27:39 UTC
Created attachment 271167 [details] Banshee log when connecting Nexus 5, with two SIGQUIT dumps When I connect my Nexus 5 running CyanogenMod 11 (Android 4.4.2) to my compouter, Banshee hangs. I've attached my log, but here are the interesting bits: "Main Thread" tid=0x0x7fb1f158b7c0 this=0x0x7fb1ee3d0010 thread handle 0x1003 state : waiting on 0x165c : Sem owns () at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Threading.Monitor.try_enter_with_atomic_var (object,int,bool&) <0xffffffff> at System.Threading.Monitor.TryEnter (object,int,bool&) <0x0004f> at System.Threading.Monitor.Enter (object,bool&) <0x00027> at (wrapper unknown) System.Threading.Monitor.FastMonitorEnterV4 (object,bool&) <0xffffffff> at Banshee.Dap.Mtp.MtpSource.SyncPlaylists () <0x0009f> at Banshee.Dap.DapSource.Flush () <0x00047> at Banshee.Dap.DapSource.Dispose () <0x00013> at Banshee.Dap.Mtp.MtpSource.Dispose () <0x0003b> at Banshee.Dap.DapService/<Unmap>c__AnonStorey2.<>m__0 () <0x00026> at Banshee.ServiceStack.Application/<Invoke>c__AnonStorey0.<>m__0 () <0x0001a> at Banshee.Gui.GtkBaseClient/<RunIdle>c__AnonStorey2.<>m__0 () <0x0001a> at GLib.Idle/IdleProxy.Handler () <0x0003f> at (wrapper native-to-managed) GLib.Idle/IdleProxy.Handler () <0xffffffff> "Threadpool worker" tid=0x0x7fb145381700 this=0x0x7fb1ee3dd030 thread handle 0x117e state : interrupted state owns () at <unknown> <0xffffffff> at (wrapper managed-to-native) Mtp.Track.LIBMTP_Get_Tracklisting_With_Callback (Mtp.MtpDeviceHandle,Mtp.ProgressFunction,intptr) <0xffffffff> at Mtp.Track.GetTrackListing (Mtp.MtpDeviceHandle,Mtp.ProgressFunction,intptr) <0x00027> at Mtp.MtpDevice.GetAllTracks (Mtp.ProgressFunction) <0x00043> at Banshee.Dap.Mtp.MtpSource.LoadFromDevice () <0x00243> at Banshee.Dap.DapSource.ThreadedLoadDeviceContents (object) <0x0006c> at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>
Interesting, I think the key thing is here: "Main Thread" tid=0x0x7fb1f158b7c0 this=0x0x7fb1ee3d0010 thread handle 0x1003 state : waiting on 0x165c : Sem owns () at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Threading.Monitor.try_enter_with_atomic_var (object,int,bool&) <0xffffffff> at System.Threading.Monitor.TryEnter (object,int,bool&) <0x0004f> at System.Threading.Monitor.Enter (object,bool&) <0x00027> at (wrapper unknown) System.Threading.Monitor.FastMonitorEnterV4 (object,bool&) <0xffffffff> at Banshee.Dap.Mtp.MtpSource.SyncPlaylists () <0x0009f> at Banshee.Dap.DapSource.Flush () <0x00047> at Banshee.Dap.DapSource.Dispose () <0x00013> at Banshee.Dap.Mtp.MtpSource.Dispose () <0x0003b> at Banshee.Dap.DapService/<Unmap>c__AnonStorey2.<>m__0 () <0x00026> at Banshee.ServiceStack.Application/<Invoke>c__AnonStorey0.<>m__0 () <0x0001a> at Banshee.Gui.GtkBaseClient/<RunIdle>c__AnonStorey2.<>m__0 () <0x0001a> at GLib.Idle/IdleProxy.Handler () <0x0003f> at (wrapper native-to-managed) GLib.Idle/IdleProxy.Handler () <0xffffffff> at <unknown> <0xffffffff> at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff> at Gtk.Application.Run () <0x0000b> at Banshee.Gui.GtkBaseClient.Run () <0x000cb> at Banshee.Gui.GtkBaseClient.Startup () <0x00042>
Yeah, it looks like it's disconnecting at that point. Also, I forgot to mention earlier, but interaction with Banshee (or mtp-tracks) appear to cause the MtpServer implementation in Android to crash. On the other hand, gvfsd-mtp seems to be able to hold out quite well.
Created attachment 271200 [details] [review] test-patch Can you please: 1) Install gui-thread-check from here (https://github.com/slluis/gui-thread-check.git) in your system. 2) After installing gui-thread-check, you should see this line when starting banshee: *** GUI THREAD INITIALIZED: 494759075 If that doesn't happen, go back to (1), maybe you installed in wrong prefix? 3) Apply this patch and test. Regardless if it fixes the bug or not, please post the output here, so I can refine the patch if needed. Thanks
Oh, for the gui-thread-check to work, you also need to apply this patch (which is only in master, and should not go back to stable, but for testing with gui-thread-check it is needed): https://github.com/GNOME/banshee/commit/9563c7ebe70bbecf80fc9accc959c2445c1fd4fe Thanks
With the patch, it no longer locks up, but the device does not appear in Banshee until a toast pops up in the phone saying that android.process.media has stopped.
(In reply to comment #5) > With the patch, it no longer locks up, Cool. Did you install gui-thread-check? Can you attach the output of the banshee run while testing it please? > but the device does not appear in > Banshee until a toast pops up in the phone saying that android.process.media > has stopped. Not quite sure understand this. A toast? How long does it take aprox?
Created attachment 271353 [details] Output
The toast is this little black coloured notification that opens two-thirds down the middle of the screen. It shows up when apps have crashed.
(In reply to comment #8) > The toast is this little black coloured notification that opens two-thirds down > the middle of the screen. It shows up when apps have crashed. And how long does it take for this to happen? Also, I'm confused, you reported this bug against 2.6.2 but on IRC you told me recently you were using gtk#3? So then you found this bug running master branch?
I tested the commit myself with gui-thread-check, and doesn't cause any GUI calls outside the main thread, so I committed it as it fixes the hang. If after this fix, you keep reproducing the toast thing, please: a) File it as a new bug. b) Test with a previous version of banshee to check if it's a regression. Thanks
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.