Bug 184059 - pilot-xfer w/ treo650 via USB aborts on -l
pilot-xfer w/ treo650 via USB aborts on -l
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: pilot-link (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-05 12:41 EST by Bowe Strickland
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-26 04:34:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bowe Strickland 2006-03-05 12:41:39 EST
(push hotsync on treo650, then.... )


[...@localhost ~]$ pilot-xfer  -p /dev/pilot -l
*** buffer overflow detected ***: pilot-xfer terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x1ec8a5]
/lib/libc.so.6(__ptsname_r_chk+0x0)[0x1ecee8]
/usr/lib/libpisock.so.9[0x85cb19]
/usr/lib/libpisock.so.9(pi_bind+0x55)[0x85ef25]
pilot-xfer[0x804f3ab]
pilot-xfer[0x804dec5]
/lib/libc.so.6(__libc_start_main+0xdc)[0x1267e4]
pilot-xfer[0x804a181]
======= Memory map: ========
00111000-00234000 r-xp 00000000 fd:01 130824     /lib/libc-2.3.91.so
00234000-00237000 r-xp 00122000 fd:01 130824     /lib/libc-2.3.91.so
00237000-00238000 rwxp 00125000 fd:01 130824     /lib/libc-2.3.91.so
00238000-0023b000 rwxp 00238000 00:00 0
00328000-0032f000 r-xp 00000000 fd:01 2789031    /usr/lib/libpopt.so.0.0.0
0032f000-00330000 rwxp 00006000 fd:01 2789031    /usr/lib/libpopt.so.0.0.0
00839000-0086c000 r-xp 00000000 fd:01 2786067    /usr/lib/libpisock.so.9.0.0
0086c000-00870000 rwxp 00032000 fd:01 2786067    /usr/lib/libpisock.so.9.0.0
00971000-0098a000 r-xp 00000000 fd:01 130818     /lib/ld-2.3.91.so
0098a000-0098b000 r-xp 00018000 fd:01 130818     /lib/ld-2.3.91.so
0098b000-0098c000 rwxp 00019000 fd:01 130818     /lib/ld-2.3.91.so
009aa000-009ab000 r-xp 009aa000 00:00 0          [vdso]
00ded000-00df8000 r-xp 00000000 fd:01 131118     /lib/libgcc_s-4.1.0-20060228.so.1
00df8000-00df9000 rwxp 0000a000 fd:01 131118     /lib/libgcc_s-4.1.0-20060228.so.1
08048000-08052000 r-xp 00000000 fd:01 2800075    /usr/bin/pilot-xfer
08052000-08054000 rw-p 00009000 fd:01 2800075    /usr/bin/pilot-xfer
087ff000-08820000 rw-p 087ff000 00:00 0          [heap]
b7f3f000-b7f41000 rw-p b7f3f000 00:00 0
bf841000-bf856000 rw-p bf841000 00:00 0          [stack]
Aborted
Comment 1 Bowe Strickland 2006-03-05 12:42:52 EST
other info:
[...@localhost ~]$ uname -r
2.6.15-1.2009.4.2_FC5
[...@localhost ~]$ rpm -qa | grep libc | xargs rpm -q
libcroco-0.6.0-6.2.1
libcap-devel-1.10-24.2
glibc-kernheaders-3.0-5.2
glibc-common-2.3.91-1
glibc-devel-2.3.91-1
glibc-2.3.91-1
libcap-1.10-24.2
libcroco-devel-0.6.0-6.2.1
glibc-headers-2.3.91-1

Comment 2 Nigel Metheringham 2006-03-11 17:31:51 EST
Confirm this on FC5T3 with all updates applied:-
  kernel-smp-2.6.15-1.1955_FC5
  kernel-smp-2.6.15-1.2041_FC5
  pilot-link-0.12.0-0.pre4.5.2.1
  udev-084-13

on i386 - P4 2.8

This obviously breaks kpilot (crashes) and gnome-pilot (crashes) too.

Additionally the udev rules are wrong for this device - the T650 (and other late
palm devices) generates 2 ttyUSB devices, only the second of which should be
symlinked to /dev/pilot.  Currently both are - the first one normally wins.

I saw this problem with
  pilot-xfer -l -p /dev/ttyUSB1

which is looking at the right device:-

[nigel@carrot ~]$ pilot-xfer -l -p /dev/ttyUSB1
*** buffer overflow detected ***: pilot-xfer terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x322965]
/lib/libc.so.6(__ptsname_r_chk+0x0)[0x322fa8]
/usr/lib/libpisock.so.9[0x437fb19]
/usr/lib/libpisock.so.9(pi_bind+0x55)[0x4381f25]
pilot-xfer[0x804f3ab]
pilot-xfer[0x804dec5]
/lib/libc.so.6(__libc_start_main+0xdc)[0x25c7e4]
pilot-xfer[0x804a181]
======= Memory map: ========
00247000-00373000 r-xp 00000000 08:01 7987608    /lib/libc-2.4.so
00373000-00376000 r-xp 0012b000 08:01 7987608    /lib/libc-2.4.so
00376000-00377000 rwxp 0012e000 08:01 7987608    /lib/libc-2.4.so
00377000-0037a000 rwxp 00377000 00:00 0
0046c000-00477000 r-xp 00000000 08:01 7988627    /lib/libgcc_s-4.1.0-20060304.so.1
00477000-00478000 rwxp 0000a000 08:01 7988627    /lib/libgcc_s-4.1.0-20060304.so.1
0051b000-00522000 r-xp 00000000 08:01 6220702    /usr/lib/libpopt.so.0.0.0
00522000-00523000 rwxp 00006000 08:01 6220702    /usr/lib/libpopt.so.0.0.0
00c43000-00c44000 r-xp 00c43000 00:00 0          [vdso]
00e17000-00e30000 r-xp 00000000 08:01 7987601    /lib/ld-2.4.so
00e30000-00e31000 r-xp 00018000 08:01 7987601    /lib/ld-2.4.so
00e31000-00e32000 rwxp 00019000 08:01 7987601    /lib/ld-2.4.so
0435c000-0438f000 r-xp 00000000 08:01 3053732    /usr/lib/libpisock.so.9.0.0
0438f000-04393000 rwxp 00032000 08:01 3053732    /usr/lib/libpisock.so.9.0.0
08048000-08052000 r-xp 00000000 08:01 3058837    /usr/bin/pilot-xfer
08052000-08054000 rw-p 00009000 08:01 3058837    /usr/bin/pilot-xfer
09bfe000-09c1f000 rw-p 09bfe000 00:00 0          [heap]
b7f3c000-b7f3d000 rw-p b7f3c000 00:00 0
b7f56000-b7f57000 rw-p b7f56000 00:00 0
bfc41000-bfc57000 rw-p bfc41000 00:00 0          [stack]
Aborted
Comment 3 Nigel Metheringham 2006-03-12 13:10:41 EST
Was going to spend some time digging into this - and got more confused....

When I originally booted the box to test this, pilot-xfer worked just fine! 
Then a couple of minutes later it would not work at all... whats more the
symptoms appear to look like a kernel level problem.

pilot-xfer bombs as shown above if the device node is not in place, if its not
read/write to the process, or if the kernel blocks it in some other way.

When the system is in its fucked state you find that /sbin/lsusb hangs when you
attempt to connect with the palm (ie hit hotsync) until such time as the connect
times out.

Putting a manual device node (rather than a udev magic one) can help, but things
are still flakey.

stracing udev shows that when the kernel is in its odd state udev is not being
called - explaining why the device nodes are not appearing.

In summary I think there is a different kernel level bug here, but that
pilot-xfer is also at fault for failing in such a messy fashion when its calling
environment is not just as it wants.

[I'm also depressed that the FC5 palm support appears to be in even worse state
than the FC4 one]
Comment 4 Bowe Strickland 2006-03-24 05:28:39 EST
If using USB, I've found you have to time it just right...

If you run

   pilot-xfer -p /dev/ttyUSB1 -i...

before initiiting hotsync, the node doesn't exist, and pilot-xfer crashes with
symptoms simlar to above.  If you initiate transfer from treo650 _first_, then
"hit enter" on above command, all works fine...

(gpilotd, however, seems to be a different case :(.)
Comment 5 Ivana Varekova 2006-11-30 09:06:41 EST
Could you please try to reproduce your bug this the latest version of pilot-link
pilot-link-0.12.1-3.fc7. 
Comment 6 Matthew Miller 2007-04-06 15:20:14 EDT
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Comment 7 Ivana Varekova 2007-07-26 04:34:54 EDT
Unfortunately there's not enough information here, therefore closing this
bugzilla. Please re-open if needed.

Note You need to log in before you can comment on or make changes to this bug.