forwarded 635671 http://bugs.jpilot.org/view.php?id=2035
tags 635671 upstream
thank
Le 03/08/11 23:14, Elliott Mitchell a écrit :
From: Ludovic Rousseau<ludovic.rouss...@gmail.com>
Le 28/07/11 02:45, Elliott Mitchell a ?crit :
Subject line tells the story. If a Palm device disconnects (such as due
to timing out during connection), jpilot's sync process will run away
trying to do a read() that is returning 0 (EOF).
What do you call "runs aways"?
Common term in some areas for "enters an infinite loop, consuming
processor time".
Can you give me a way to reproduce the problem in documented steps?
May be tricky to do properly. Needs a USB Palm device (such as Handspring
Visor, Treos, others). Simplest simulation might be to stick a
sleep(300); in after the open() of /dev/pilot.
The real world situation is to plug in the (USB) device, press the
Hotsync button, and then you select JPilot's sync button. If your timing
is off, crucially a bit too slow with JPilot's sync button (likely best
to simulate with a sleep(300) between the open() and first write(), as
above), the device will timeout before JPilot manages to start talking.
I'm pretty sure the sequence is roughly, /dev/pilot appears when the
Hotsync button is pressed. JPilot open()s the device, but doesn't manage
to get the device's attention before it times out, and so /dev/pilot
disappears. Meanwhile, JPilot is stuck in an infinite loop somewhere
doing a read(), which is giving back 0 (EOF).
Come to think of it, this may actually be a kernel bug, since I would
expect a read() error (EIO perhaps?).
I forwarded the bug upstream.
But do not expect a fix soon. jpilot and pilot-link are (nearly) dead
upstream.
Bye
--
Dr. Ludovic Rousseau
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
