Hi Martin--

On 01/06/2010 02:29 AM, Martin Pitt wrote:
> Hello Daniel,
> 
> Daniel Kahn Gillmor [2010-01-06  1:28 -0500]:
>> [ 1875.523376] devkit-disks-da[2335]: segfault at c ip 080660da sp bffb23f0 
>> error 4 in devkit-disks-daemon[8048000+28000]
> 
> In order to get some better idea what happens, please do 
> 
>   gdb --args /usr/lib/devicekit-disks/devkit-disks-daemon --replace
> 
> as root, then "run". Then replicate the steps to cause a crash. Once
> gdb catches the crash, do "bt full". Please copy the entire gdb output
> here, plus a couple of lines of devkit-disk-daemon's output, so that
> we can see what it was trying to do.

It seems to be a child process that's segfaulting (the one that shows up 
in ps as "devkit-disks-daemon: polling /dev/sdc /dev/sdb").

So before doing "run" i needed to do "set follow-fork-mode child" to
make sure i caught the segfault.

unfortunately, i don't have the debug symbols for devicekit, so the
backtrace looks pretty unintelligible:

**** EMITTING CHANGED for 
/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/sdc1
**** CHANGED 
/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/sdc1
**** REMOVING 
/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/sdc1
**** EMITTING REMOVED for 
/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/sdc1
**** REMOVING 
/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
**** EMITTING REMOVED for 
/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

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b9a720 (LWP 7414)]
0x080660da in ?? ()
(gdb) bt
#0  0x080660da in ?? ()
#1  0xb7de3877 in g_list_foreach () from /lib/libglib-2.0.so.0
#2  0x0806658a in ?? ()
#3  0xb7e1c88d in ?? () from /lib/libglib-2.0.so.0
#4  0xb7de5f28 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#5  0xb7de96b3 in ?? () from /lib/libglib-2.0.so.0
#6  0xb7de9b7a in g_main_loop_run () from /lib/libglib-2.0.so.0
#7  0x08066386 in ?? ()
#8  0x08066af8 in ?? ()
#9  0xb7c6fb55 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#10 0x0804ce21 in ?? ()
(gdb) 

It turns out i don't need to mount the partition at all to trigger the crash, 
btw.

Just insert the USB stick, wait for devkit to recognize it, then pull it out 
(i'm 
not running any desktop environment or anything that does automounting on device
insertion).

Attached is the first 1KB of the USB stick (extracted with
"dd if=/dev/sdc bs=1024 count=1"), if you want to try to replicate it yourself.

The kernel and fdisk see the device like this:

0 d...@pip:~/tmp$ grep sdc /proc/partitions 
   8       32     978944 sdc
   8       33     978912 sdc1
0 d...@pip:~/tmp$ /sbin/fdisk -l /dev/sdc

Disk /dev/sdc: 1002 MB, 1002438656 bytes
223 heads, 63 sectors/track, 139 cylinders
Units = cylinders of 14049 * 512 = 7193088 bytes
Disk identifier: 0x54830579

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         237     1664775    c  W95 FAT32 (LBA)
0 d...@pip:~/tmp$ 

I'm not entirely sure how i got the thing into this weird state, but i suppose
that doesn't really matter from devkit's perspective (though it might be another
but if i can figure it out).

If i can get some time, i'll try to rebuild devicekit-disks with debug symbols
to try to get a better backtrace.

Regards,

        --dkg

Attachment: sdc.1k
Description: Binary data

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Pkg-utopia-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-utopia-maintainers

Reply via email to