We get gazillions of dupes for this crash: #0 0x00007fc4138ce4e5 in raise () from /lib/libc.so.6 #1 0x00007fc4138d1f80 in abort () from /lib/libc.so.6 #2 0x00007fc4138c74a1 in __assert_fail () from /lib/libc.so.6 #3 0x00007fc413c0d199 in sk_disk_set_blob (d=0x0, blob=<value optimized out>, size=<value optimized out>) at atasmart.c:2701 p = <value optimized out> left = <value optimized out> idv = <value optimized out> sdv = <value optimized out> stv = <value optimized out> bssv = <value optimized out> __PRETTY_FUNCTION__ = "sk_disk_set_blob" #4 0x000000000040e99a in drive_ata_smart_refresh_data_completed_cb ( context=0x0, device=0x1f25c50, job_was_cancelled=<value optimized out>, status=<value optimized out>, stderr=<value optimized out>, stdout=<value optimized out>, user_data=0x1f674e0) at devkit-disks-device.c:7912 rc = <value optimized out> good = <value optimized out> num_bad_sectors = <value optimized out> temperature_mkelvin = <value optimized out> power_on_mseconds = <value optimized out> asd = <value optimized out> d = (SkDisk *) 0x1f280c0 blob = (guchar *) 0x0 blob_size = 1 time_collected = <value optimized out> is_failing = <value optimized out> is_failing_valid = <value optimized out> collect_attrs_data = {attributes = 0x0, has_bad_attributes = 1} db = <value optimized out> #5 0x000000000040cb5b in job_child_watch_cb (pid=<value optimized out>, (full trace at http://launchpadlibrarian.net/30901828/Stacktrace.txt, but that's the interesting bit). The full assertion message is: devkit-disks-daemon: atasmart.c:2701: sk_disk_set_blob: Assertion `blob' failed. This crashes in this code in src/devkit-disks-device.c: blob = (gchar *) g_base64_decode (stdout, &blob_size); if (sk_disk_open (NULL, &d) != 0) { if (context != NULL) { throw_error (context, DEVKIT_DISKS_ERROR_FAILED, "unable to open a SkDisk"); } goto out; } if (sk_disk_set_blob (d, blob, blob_size) != 0) { as the stack frame #4 shows, blob == NULL (which triggers the assertion in libatasmart).
Some analysis: - According to some duplicates, this crash is 100% reproducible with some devices (unfortunately with none of mine) - stdout is not NULL (the -O2 optimized that away unfortunately, but the condition is checked before) - devkit-disks-helper-ata-smart-collect returned with exit code 0 (condition is checked before) - blob_size could be already written by g_base64_decode(), or just be uninitialized, so we can't rely on the origin of "1" - g_base64_decode() code shows that it can only return NULL in those conditions: g_return_val_if_fail (text != NULL, NULL); g_return_val_if_fail (out_len != NULL, NULL); input_length = strlen (text); g_return_val_if_fail (input_length > 1, NULL); We already know that text != NULL (which is "stdout" here), and we also know that out_len != NULL (it's a pointer to a local variable. So it seems that the reason is that stdout is just a single character. I propose to intercept this condition gracefully and add some debug logging what the output is, so that in the future we can get to the root cause.
Created attachment 31118 [details] [review] git formatted patch
I asked folks in the Ubuntu bug report to test the patch and supply the daemon output with the message. I'm eager to see what the bad output looks like.
The patch was confirmed to fix the crash. It seems that the output was empty: **** EMITTING CHANGED for /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda helper(pid 14142): completed with exit code 0 (devkit-disks-daemon:14138): GLib-CRITICAL **: g_base64_decode: assertion `input_length > 1' failed (devkit-disks-daemon:14138): devkit-disks-daemon-WARNING **: Error decoding ATA SMART data: invalid base64 format: **** ADDING /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0/block/sdc (I got two different logs, bot the same).
(In reply to comment #4) > The patch was confirmed to fix the crash. It seems that the output was empty: > > **** EMITTING CHANGED for > /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda > helper(pid 14142): completed with exit code 0 > > (devkit-disks-daemon:14138): GLib-CRITICAL **: g_base64_decode: assertion > `input_length > 1' failed > > (devkit-disks-daemon:14138): devkit-disks-daemon-WARNING **: Error decoding ATA > SMART data: invalid base64 format: > **** ADDING > /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.0/host5/target5:0:0/5:0:0:0/block/sdc > > (I got two different logs, bot the same). > Applied, thanks for tracking this down. FWIW, I think there's a bug in libatasmart - I often get this error Error retrieving ATA SMART data: helper failed with exit code 1: Failed to read smart data for /dev/sda: No such file or directory when refreshing the SMART data from Palimpsest. Funny enough I can't reproduce when doing 'skdump /dev/sda' from the command line. I'll try to track this down when I find some free cycles.
(In reply to comment #5) > FWIW, I think there's a bug in > libatasmart - I often get this error > > Error retrieving ATA SMART data: helper failed with exit > code 1: Failed to read smart data for /dev/sda: No such file > or directory > > when refreshing the SMART data from Palimpsest. Funny enough I can't reproduce > when doing 'skdump /dev/sda' from the command line. I'll try to track this down > when I find some free cycles. Just FYI, I tracked this down - see bug 25543 for a patch that fixes this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.