debugging usb segfault in pilot-xfer

[dentonlt]

Hey there - I'm hoping that curaga will be browsing by to catch a usb-utils question.

I'm trying to get pilot-xfer (http://www.pilot-link.org/) working on my TC installation. I previously had it running on TC + HP Evo N410c and it was perfect. It doesn't play nice on my netbook (HP Mini 1001), however ... so I think it has to do with the USB hardware on this laptop.

I have an intermittent bug - pilot-xfer locks up at random places, random times. I've been through the pilot-xfer code quite a lot, and the best I can pin down is that my hardware doesn't like disconnecting from the Palm. Most of the time, pilot-xfer just locks up after finishing its work (backup/sync fine), but it doesn't like to close up. It doesn't seem to crash out in a consistent place in the pilot-xfer code, so I think it depends upon when the usb disconnects. Frankly, I'm at a loss since the target keeps moving.

I've caught a usb segfault just once in dmesg:

Code: [Select]

usb 2-1: new full speed USB device using uhci_hcd and address 6
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: USB disconnect, address 6
lt-pilot-xfer[12410]: segfault at 0 ip b7f5a49f sp bffb47b4 error 4 in libusb-0.1.so.4.4.4[b7f59000+3000]
usb 2-1: new full speed USB device using uhci_hcd and address 7
usb 2-1: configuration #1 chosen from 1 choice
usb 2-1: USB disconnect, address 7

lsusb shows the following when my Palm is connected:

Code: [Select]

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 10f1:1a08 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 023: ID 0830:0060 Palm, Inc. Tungsten C/E/T/T2/T3 / Zire 71
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 13d3:3249 IMC Networks
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

And lsusb shows this when my Palm disconnects:

Code: [Select]

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 10f1:1a08 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 13d3:3249 IMC Networks
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The whole pilot-link suite compiles nicely provided compiletc and usb-utils. I'm using the options from the wiki:

Code: [Select]

export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti"
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

And I've run ./configure with a slew of different combinations to try stumbling upon a solution. No luck. Currently using:

Code: [Select]

./configure --enable-conduits --enable-libusb --enable-threads --disable-libtool-lock --disable-debug --prefix=/usr/local

Then I make, make DESTDIR=/tmp/pkg install.

I'm at a loss. I've compiled/used pilot-xfer on TC with different hardware no problem, and other distros no problem. I don't know why this one is odd! Any advice for where/how to find out what's wrong? Palm OS is aging hardware, I know, but it's still a great use.

I can hobble through as is, but it's extension-ready if this has a fix. TIA.

[Juanito]

lt-pilot-xfer[12410]: segfault at 0 ip b7f5a49f sp bffb47b4 error 4 in libusb-0.1.so.4.4.4[b7f59000+3000]

I believe libusb-0.1.so.4.4.4 is the wrapper that makes libusb-1.x look like libusb-0.x - maybe this is the cause of the problem?

You could try libusb-1.x without the wrapper or the legacy libusb-0.1.12?

[curaga]

There have been updates to all three components of the usb-utils extension, they might have fixed the bug. Also, the segfault was within libusb, so the pilot-link code might be just fine.

I suggest first running pilot-xfer inside gdb, built with debug options. It might be necessary to do the same to libusb to get meaningful output, but try first.

[Juanito]

I played around with the latest versions of the usb stuff:

libusb-0.1.12 - legacy libusb
libusb-1.0.3 - new libusb
libusb-compat-0.1.3 - makes new libusb look like legacy libusb
usbutils-0.86  - depends on libusb-legacy or libusb+libusb-compat

I guess it would make sense to make two extensions:

libusb = libusb+libusb-compat
usb-utils

I don't see much point in a libusb-legacy

comments?

[dentonlt]

Thanks for the assistance. I'm testing again now (running with gdb) and will get back with details when I have them.

Personally, I'm fine with usbutils+libusb as one extension right now ... unless I find that I need them separated to get this working!

EDIT:
It seems that there is a problem exiting one of the threads (LWP) that take care of usb connect/disconnect. The thread library doesn't seem to have debugging info, though ... gdb says:

Code: [Select]

Cannot initialize thread debugging library: Versions of libpthread and libpthread_db do not match

I'm working out how to make that happen. I'll keep digging, but it's slow going for now.

I also took time to run/gdb the same under Xubuntu (same hardware), and I can't make it crash. I figure that means it can be worked out somehow.

EDIT:
Built libusb w/ debugging info. pilot-xfer locks up just after libusb connection close ... of course, I haven't figured out exactly why yet.

EDIT:
Ah ... it locks when calling usbi_remove_pollfd. I'll have to set this aside and revisit.

[Juanito]

the latest libusb is now posted in libusb.tczl if you'd like to try with this.

[dentonlt]

Juanito - thanks for that (libusb.tczl). Unfortunately, problem persists. I rebooted into base, built using only compiletc and the new libusb.tczl. Builds fine, but has the same problem 

I'll keep at it. Current plan is to figure out how to get the threading libs to match, then I can debug down to the right spot. At least that's the plan ...

[^thehatsrule^]

EDIT:
It seems that there is a problem exiting one of the threads (LWP) that take care of usb connect/disconnect. The thread library doesn't seem to have debugging info, though ... gdb says:

Code: [Select]

Cannot initialize thread debugging library: Versions of libpthread and libpthread_db do not match


Looks like the extension is from 1.x.  It contains the older library and needs to be updated.

[dentonlt]

I have still been working on this, albeit slowly. The pilot-link.org site is down (perhaps indefinitely), so I have nowhere to post questions.

In the end, I don't believe it is the libusb or libusb compatibility code. Pilot-tools has its own file libusb.c, and so the debug output gets confusing against the libusb library debug output ...

Anyhow, two bugs found in pilot-link thus far:

./configure uses HAVE_PTHREADS, should read HAVE_PTHREAD

/libpisock/libusb uses PTHREAD_CANCEL_ASYNCHRONOUS, which is probably causing the lock-up when closing the connection ... testing with PTHREAD_CANCEL_DEFERRED

If I can get this going reliably, I'll post an extension.

[dentonlt]

Completed updating pilot-link-0.12.4 to support libusb-1.0. Now works well - I'll submit an extension.

The pilot-link project will probably produce no more updates (it supports rather old, though effective hardware). I've mentioned to the maintainer that I made these changes, but there is nowhere to formally submit them to that project. I'll post them at my own site and mention this in the extension's info file.

[^thehatsrule^]

The best way would probably be to submit those changes/src along with the extension.

[dentonlt]

Done as suggested - thanks for the help on this one.