>From: Ludovic Rousseau <[email protected]> > 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?). -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | [email protected] PGP F6B23DE0 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
