GNOME Bugzilla – Bug 744775
Rhythmbox crashes when trying to access Android device.
Last modified: 2016-02-03 08:16:07 UTC
Reporting the bug here as recommended by this thread on AskUbuntu: http://askubuntu.com/a/586041/17041 Debug output on Pastebin: http://paste.ubuntu.com/10301400/ System information: OS: Ubuntu 14.10 libmtp 1.1.8 Rhythmbox 3.0.3 Android: Samsung Galaxy S5 (SC-04F), Android 5.0 How to create the problem: 1 Open Rythmbox. 2 Connect Android by USB (2.0 - I don't have 3.0) 3 Android device appears listed in the left side of the interface. However, it does not find any music files on the device or display any anything that indicates it is scanning for music, or any other activity. Nothing happens. 4 Wait a few minutes to be sure it isn't just a matter of delay. 5 Click on the "Properties" button to access information about the attached Android device. 6 Rhythmbox crashes. Other notes: I have general MTP connection problems that are consistent across two Ubuntu 14.10 computers, two Android devices, Banshee, and Rhythmbox. I'm hoping fixing this one specific problem with Rhythmbox will shed light on the underlying problem and lead to a solution that will give me full functionality across all devices, platforms, and programs. Thanks.
I am experiencing the same problem with Rhythmbox 3.2.1 and libmtp 1.1.9 on Arch Linux x64, using GNOME 3.16.2
Similar issue on Linux 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64 GNU/Linux using Rhythmbox 3.2.1 GDB output: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b0df3c in rb_sync_settings_sync_category () from /usr/lib/librhythmbox-core.so.9
Installed debug symbols and ran again. Crash happens in rb-sync-settings.c:170 Looked it up on https://git.gnome.org/browse/rhythmbox/tree/sources/sync/rb-sync-settings.c?id=v3.2.1 It is the return line in: gboolean rb_sync_settings_sync_category (RBSyncSettings *settings, const char *category) { RBSyncSettingsPrivate *priv = GET_PRIVATE (settings); return _get_boolean_with_default (priv->key_file, category, CATEGORY_ENABLED_KEY, FALSE); } Since the settings pointer seems to be accessed without issues by line 169, I tentatively conclude that the category pointer is invalid.
More detailed GDB output: Program received signal SIGSEGV, Segmentation fault. rb_sync_settings_sync_category (settings=0x0, category=category@entry=0x7ffff7b8bc4c "music") at rb-sync-settings.c:170 This means that the character pointer is NOT the issue, since it seems to be set to the value of “music” correctly.
Oh, wait, the settings pointer is zero, which I guess means a NULL pointer.
Interesting, when trying to reproduce another time, the device was identified as “Nexus 7” instead of “Media device” and now I could safely press the Properties and Sync buttons. However Rhythmbox does not in fact correctly detect the properties, since it says there's no media on the device. When I try to sync it says that the available 9.2 exbibytes on the device are insufficient to sync my music to it. Apparently I have a far bigger storage space on my Nexus 7 than I realised, but I also have far more music than I realised.
I managed to get the system in the error-prone mode where the device is detected as “Media device” and disabled the MTP on my Nexus. This showed a very long list of repeated: (rhythmbox:5540): Rhythmbox-WARNING **: libmtp error: Error 02ff: PTP: I/O error (rhythmbox:5540): Rhythmbox-WARNING **: libmtp error: PTP Layer error 02ff: get_track_metadata(): call to ptp_mtp_getobjectpropssupported() failed. For some reason this references a PTP (Picture Transfer Protocol?) layer error. I guess MTP is a layer on top of PTP. Apparently sometimes it fails to get the object properties. This may be an indication of why the device is not detected by name, and why the settings pointer (does it reference the properties?) is NULL.
I was about to report this as fixed in master, but it only worked once and now I continuously see Program received signal SIGSEGV, Segmentation fault. 0x00007fffbe133d6b in update_free_space_next (source=0x19363a0) at rb-android-source.c:143 143 file = G_FILE (priv->query_storage->data); (gdb) bt
+ Trace 235871
The above was possibly caused by a bad SD card, I now now access properties every time with git master. but.. SD card space was not displayed initially, I've created a "Music" folder on it and added some songs and suddenly I see all storage space in properties. Rhythmbox then shows "Scanning android device" sync does not work, I'm just seeing an error messagebox "Error transferring track: could not open resource for writing"
If you don't unlock the device before trying to access it, it will produce a coredump every time. (bt same as comment 8) As for why sync is not working, I'm getting 'Operation not supported'. I can manually create files and move things through nautilus as long as they are not on a gvfs device. Possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=1187842 (copying between two gvfs locations) Could not open location mtp://[usb:001,008]/Phone/Music/Telekinesis/Unknown/00%20-%20Alienated.mp3 for writing: Operation unsupported (01:54:19) [0x55b9648d7990] [rb_encoder_gst_emit_completed] rb-encoder-gst.c:139: couldn't get size of destination mtp://[usb:001,008]/Phone/Music/Telekinesis/Unknown/00%20-%20Alienated.mp3: File not found (01:54:19) [0x55b9648d7990] [encoder_completed_cb] rb-track-transfer-batch.c:561: encoder finished (error: Could not open resource for writing.) (01:54:19) [0x55b9648d7990] [track_done_cb] rb-transfer-target.c:366: fatal transfer error: Could not open resource for writing. (01:54:19) [0x55b9648d7990] [_rb_track_transfer_batch_cancel] rb-track-transfer-batch.c:445: batch being cancelled
commit 7a40d34 fixes the crash when accessing a device that doesn't have mtp enabled, and commit c69e4fd adds a hint to the user that they need to unlock or enable mtp if no storage is found on the device. If you have other problems with android devices that do not involve rhythmbox crashing when initially accessing the device, please open a new bug.
This works (doesn't crash) but it never refreshes, so it doesn't retry to access to device after unlocking. Restarting rhythmbox with device unlocked, it works as expected.
Should possibly disable properties & sync in locked/inaccessible state
please open a new bug for those non-crash issues.