On Mar 26, 2013, at 9:07 AM, Michael Richardson <m...@sandelman.ca> wrote:
> The fault seems to be inside of libusb:
>
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> Core was generated by `/usr/sbin/tcpdump icmp'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00007feae033fb50 in __opendirat () from /usr/lib/libc.so.6
> (gdb) bt
> #0 0x00007feae033fb50 in __opendirat () from /usr/lib/libc.so.6
> #1 0x00007feadfc68e9e in ?? () from /usr/lib/libusb-1.0.so.0
> #2 0x00007feadfc6153c in libusb_get_device_list () from
> /usr/lib/libusb-1.0.so.0
> #3 0x00007feae0647a9f in canusb_platform_finddevs () from
> /usr/lib/libpcap.so.1
>
> It appears that it faults if there are no USB devices, which wouldn't be
> surprising for a VM.
It faults because it's being handed a NULL first argument, and it's being
handed a NULL argument because libpcap isn't checking whether libusb_init()
succeeded or not.
So, while it's crashing inside libusb, that's because libpcap wasn't using
libusb correctly. If you've filed a libusb bug, you might want to close it.
This bug was fixed last year in
commit 9f8827ee41bbf24c7dc98d5f6ff3790756e378f4
Author: Guy Harris <g...@alum.mit.edu>
Date: Mon Aug 6 15:25:30 2012 -0700
Check whether libusb_init() succeeds, and give up if it doesn't.
libusb_init() isn't guaranteed to succeed; it returns a (presumably)
non-zero error on failure. If it doesn't return 0, just give up - we
presumably don't have a valid libusb_context pointer, which is probably
what's causing crashes when we call libusb_get_device_list() on a system
with no usbfs mounted.
This fixes bug 3554749 in the tracker, and a bunch of upstream bugs.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
