| Summary: | >=dev-libs/openobex-1.3, app-mobilephone/obexftp-0.22: Does not open USB devices properly, causes a segfault (inside dev-libs/libusb-0.1.12-r4) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | gfl3162+gbugzilla |
| Component: | [OLD] Library | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | dsd, robbat2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 547828 | ||
|
Description
gfl3162+gbugzilla
2008-07-13 00:11:55 UTC
Does libusb-0.1.12-r3 (or any version for that matter) work? I don't have any OBEX hardware, so it's hard for me to test this. No, the same problem occurs on other versions of libusb. Since the linux.c:210 line is an ioctl call, there's not much we can do in libusb. The problem lies either with your kernel, your hardware or openobex. If it crashed in an ioctl then dmesg should have lots of freshly squeezed juicy info I recompiled the kernel with USB debug support, but dmesg does not show any extra information that explains the segfault. Is there any clues on howto debug this segfault? I found out the following: running 'strace obexftp -u 0 -l' show that obexftp runs these two ioctls before segfaulting: ioctl(138421400, USBDEVFS_SETINTERFACE, 0xbfd5ccd4) = -1 EBADF (Bad file descriptor) ioctl(138421400, USBDEVFS_RELEASEINTERFACE, 0xbfd5ccf4) = -1 EBADF (Bad file descriptor) Why would obexftp be using 138421400 as a file descriptor number? I found why it segfaults:
ret = ioctl(dev->fd, IOCTL_USB_SUBMITURB, &urb);
but dev = 0x28. In gdb:
(gdb) print dev->fd
Cannot access memory at address 0x28
Backtrace:
#0 0xb7e29be2 in usb_urb_transfer (dev=0x28, ep=5, urbtype=3, bytes=0x815e1a0 "\200", size=26, timeout=10000) at linux.c:210
#1 0xb7f78b93 in obex_transport_write (self=0x3e8, msg=0x815e180) at obex_transport.c:436
#2 0xb7f779ba in obex_data_request (self=0x814e068, msg=0x815e180, opcode=128) at obex_main.c:217
#3 0xb7f78653 in obex_object_send (self=0x814e068, object=0x816fe38, allowfinalcmd=1, forcefinalbit=0) at obex_object.c:547
#4 0xb7f7935a in obex_client (self=0x814e068, msg=0x0, final=0) at obex_client.c:113
#5 0xb7f770b9 in OBEX_Request (self=0x28, object=0x3e8) at obex.c:573
#6 0xb7f875a1 in cli_sync_request (cli=0x814e008, object=0x28) at client.c:448
#7 0xb7f87fdc in obexftp_connect_src (cli=0x814e008, src=0x0, device=0x0, port=0, uuid=0x804d238 "{\225<\021\230NRT", uuid_len=16) at client.c:725
#8 0x08049001 in cli_connect_uuid (uuid=0x804d238 "{\225<\021\230NRT", uuid_len=16) at obexftp.c:268
#9 0x08049613 in cli_connect () at obexftp.c:314
#10 0x08049d23 in main (argc=4, argv=0xbffceea4) at obexftp.c:624
BTW I'm on openobex 1.5, libusb 0.1.12-r4, obexftp 0.22 (so only openobex was updated).
the dev variable in that case is self->trans.self.usb.dev_data inside openobex. This is the line that crashes in openobex: 436 actual = usb_bulk_write(self->trans.self.usb.dev_data, 437 self->trans.self.usb.data_endpoint_write, 438 (char *) msg->data, msg->data_size, 439 USB_OBEX_TIMEOUT); So it seems that openobex is screwing up opening the device or one it's internal variables is being overwritten. Somebody in the mobile herd with the hardware needs to dig and see that openobex sets up it's USB connections correctly. It's not libusb at fault at all. Updating the summary for easier browsing as I expect a lot of libusb bugs soon while we migrate to libusb-1. mobile: reping. please see comment 8 and fix this? The package has broken functionality. (In reply to comment #10) > mobile: reping. please see comment 8 and fix this? The package has broken > functionality. Feel free to commit the fix if you have it [QA] The mobile-phone herd has been dissolved to maintainer-needed due to absence. This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers is this still hapenning with obexftp-0.24? |
