GNOME Bugzilla – Bug 322903
Gnome Pilot Backup Function doesn't work and result in "File" and "Test" function fail
Last modified: 2006-08-28 08:11:09 UTC
Please describe the problem: When using Gnome-Pilot pkg for Solaris USB port. "Backup" doesn't work. And if "Backup" has failed, it result in "File" and "Test" fuction fails,unless Del current "Device" and "Pilot" and start a new link. Steps to reproduce: Connect palm515 with X86 machine by USB port. Installed NV19 and Gnome-Pilot pkgs for USB port. 1.Backup Setting as follows: Conduit Actions: Action:Enabled One Time Action:None Conduit Settings: Backup dirctory:/Mypilot Only backup changed bases:no Remove local base if deleted on pilot:no # of old backups to keep:0 2.Hit Sync button on palm. Actual results: Error occurs on PC as follows: The Application "gpilotd" has quit unexpectedly. You can inform the developers of what happened to help them fix it. Or you can restart the application right now. At the same time,Error occurs on palm as follows: The connection between your handheld computer and the desktop was lost.Some of y our data was NOT backuped up. Plaease check your setup and try again. Expected results: Does this happen every time? Other information: It happened on Solaris.
Created attachment 55459 [details] [review] the proposed patch It works for this bug on Solaris.
Having had a quick look, much of this patch relates to porting work required to use the new 0.12.0 pilot-link API. The bulk of the changes were committed to CVS last November (sorry, must have crossed with your work). There have been a couple more changes yesterday. The CVS version should compile against 0.12.0 and 0.11.8 API versions. Can the original problem be reproduced with the current gnome-pilot CVS? By the way, if verifying this bug I strongly recommend compiling pilot-link from the current CVS version. Thanks.
Hi,Matt The original problem isn't reporducible with the current gnome-pilot CVS. However,I compiled pilot-link-0.12.0-pre4 instead of the current CVS version of pilot-link when verifying the bug. Because I have a problem below if using the current CVS version of pilot-link. After building the current CVS version of gnome-pilot successfully based on pilot-link CVS codes, a error below happened when starting up "/usr/libexec/gpilotd". "(gpilotd:12950): gpilotd-WARNING **: An error occured while getting the pilot's system data". My machine OS: Linux; Os version: Suse 9; pilot-link version: current CVS version; gnome-pilot version: current CVS version. Thanks.
I have seen that behaviour too. If your issue has the same cause, then try setting the timeout parameter to zero. See pilot-link bug #1585: http://bugs.pilot-link.org/1585 Despite opening the bug and posting a patch, this bug has not yet been fixed in the pl CVS :( It's going to be annoying for gnome-pilot if this bug is present in pl 0.12.0-final... Please feel free to mail pilot-link-devel or pl developers if you find my workaround fixes your problem!
gnome-pilot works well by setting the timeout parameter to zero with gnome-pilot CVS + pilot-link CVS. But the bug can still be reporducible. Backup function only work once.
Please give more information, so that I can reproduce this bug. 1. what sync method are you using (usb? network?) 2. does gpilotd crash, or not? 3. what console error messages does gpilotd give? 4. does backup work one more time if you restart gpilotd? 5. do other conduits continue to work? Matt
Steps to reproduce: Connect PalmOne Treo 600 with Linux machine by USB port. OS: Suse 9. Gnome-pilot version: current CVS. Pilot-link version: current CVS. 1.Backup Setting as follows: Conduit Actions: Action:Enabled One Time Action:None Conduit Settings: Backup dirctory:/Mypilot Only backup changed bases:no Remove local base if deleted on pilot:no # of old backups to keep:0 2.Hit Sync button on palm. Results: The first sync works successfully. Hit hotsync button on palm again after the first sync: 1./usr/libexec/gpilot holds at: backupconduit-Message: AddressTitlesDB not modified since last sync backupconduit-Message: To Do List_todo_appl_a68k not modified since last sync gpilotd-Message: Synchronization ended gpilotd-Message: setting PILOTRATE=57600 2. Palm device has on error messages. 3. Other conduits don't continue to work. Even the GUI also hold. 4. "pkill gpilotd" and restart gpilotd, backup also can work once.
Jerry, this looks pretty strange. I'll try reproducing, but I don't fancy my chances (as backup has been reliable for me, as far as I can tell, with pilot-link almost as per CVS). Any further debugging you can do might be useful -- can you attach to the frozen gpilotd with gdb and see where you are stuck? Does strace gpilotd reveal anything?
Matt, I set a breakpoint at gpiltod.c:115, "run" and then "next" some times, the program held at: (gdb) next 192 sd = pi_accept_to (listen_sd, NULL, NULL, device->timeout); (gdb) print device->timeout $2 = 0 (gdb) next ------------holding------------ If device->timeout was set to 2 in gdb, it's ok. (gdb) next 192 sd = pi_accept_to (listen_sd, NULL, NULL, device->timeout); (gdb) set device->timeout=2 (gdb) next 193 if (sd < 0) { (gdb) So maybe your workaround that device->timeout set to zero isn't the inherent solution.
This time device->timeout was set to zero and "step" to "step" after "sd = pi_accept_to (listen_sd, NULL, NULL, device->timeout)". results: . . . (gdb) next 192 sd = pi_accept_to (listen_sd, NULL, NULL, device->timeout); (gdb) print device->timeout $3 = 0 (gdb) step pi_accept_to (pi_sd=23, addr=0x0, addrlen=0x0, timeout=0) at socket.c:1098 1098 if (!(ps = find_pi_socket(pi_sd))) { . . . (gdb) step 284 if (timeout == 0) (gdb) step 285 select(ps->sd + 1, &ready, 0, 0, 0); (gdb) bt
+ Trace 66819
.........................holding here..................... So I think maybe the problem lies here.
Sorry for the wrong bug information. When Backup failed, there's a error message on the Palm device: Error occurs on palm as follows: The connection between your handheld computer and the desktop was lost.Some of y our data was NOT backuped up. Plaease check your setup and try again.
(In reply to comment #10) > This time device->timeout was set to zero and "step" to "step" after "sd = > pi_accept_to (listen_sd, NULL, NULL, device->timeout)". results: > . > . > . > (gdb) next > 192 sd = pi_accept_to (listen_sd, NULL, NULL, device->timeout); > (gdb) print device->timeout > $3 = 0 > (gdb) step > pi_accept_to (pi_sd=23, addr=0x0, addrlen=0x0, timeout=0) at socket.c:1098 > 1098 if (!(ps = find_pi_socket(pi_sd))) { > . > . > . > (gdb) step > 284 if (timeout == 0) > (gdb) step > 285 select(ps->sd + 1, &ready, 0, 0, 0); > (gdb) bt > #0 s_poll (ps=0x80dded8, timeout=0) at unixserial.c:285 > #1 0x40922de3 in pi_serial_accept (ps=0x80dded8, addr=0x0, addrlen=0x0) at > serial.c:488 > #2 0x40925fe6 in pi_accept_to (pi_sd=23, addr=0x0, addrlen=0x0, timeout=0) at > socket.c:1108 > #3 0x0804d575 in sync_device (device=0x80967b0, context=0x8096698) at > gpilotd.c:192 > #4 0x0804e32b in visor_devices_timeout (data=0x8096698) at gpilotd.c:941 > #5 0x40898d76 in g_timeout_dispatch (source=0x80b5168, callback=0x804e1c0 > <visor_devices_timeout>, user_data=0x17) > at gmain.c:3301 > #6 0x40898187 in g_main_context_dispatch (context=0x808a508) at gmain.c:1942 > #7 0x4089a8c7 in g_main_context_iterate (context=0x808a508, block=1, > dispatch=1, self=0x8059990) at gmain.c:2573 > #8 0x4089a9c3 in g_main_context_iteration (context=0x808a508, may_block=1) at > gmain.c:2632 > #9 0x0804d1fe in main (argc=1, argv=0xbffff3d4) at gpilotd.c:1121 > (gdb) step > .........................holding here..................... > > So I think maybe the problem lies here. > unixserial.c is pilot-link's file.
Hmm. I can think of two things to try. 1. does gpilotd lock up immediately after the successful sync? Could it be simply that gpilotd, after finishing a sync, sees that the USB device is still hanging around, and erroneously tries another sync and then gets stuck in the serial poll() with no timeout? If so, then putting in a short (say 1-second) delay in gpilotd after a successful sync might be sufficient. 2. A better alternative, if it works, might be to apply the pilot-link patch I posted to bug 1585 on bugs.pilot-link.org: http://bugs.pilot-link.org/file_download.php?file_id=592&type=bug and then a non-zero timeout should work properly.
I think I've found the cause of the gpilotd freeze. Do you have more than one configured USB 'device'? (i.e. perhaps one 'pilot' but two 'devices' in the capplet) I've been able to reproduce this by using the gpilotd-control-applet to configure a second 'device' that watches the ttyUSB device. After the first sync completes, gpilotd tries to sync the second configured device, but the palm has signed off. The simple fix is to prevent gpilotd trying to sync more than one USB device. A proper fix would be to enforce the 'single USB device' condition in the capplet, but that's not a one-liner and the visor module stuff is due to be ripped out at some stage so I'm not going to spend too long on this right now. Jerry, can you verify that this patch fixes the problem: --- gpilotd.c.~1.146.~ 2006-03-06 20:21:16.000000000 +0000 +++ gpilotd.c 2006-03-13 20:52:31.000000000 +0000 @@ -955,6 +955,7 @@ visor_devices_timeout (gpointer data) if (!visor_net) device->type = PILOT_DEVICE_USB_VISOR; + break; /* don't try to sync any more devices! */ } l = l->next; }
Hi,Matt The answer is no. There's only one configured device in capplet. I have done a test to the two patches you mentioned above, one for pilot-link and the other for gnome-pilot. It is a pity that both of them can't resolve the problem.
Hi Jerry, That's a shame that the patches don't fix it. You could try adding a short sleep() after the sync completes (where the 'break' statement was added) to see if that sorts it out. My suspicion is that gpilotd is attempting a further sync immediately after finishing the first sync. This can happen if there are multiple configured devices, but I guess it could also happen if the USB device persists for a short period after the sync completes.
Update: I have added a couple of sleeps to avoid attempting a new sync immediately after completing one which I believe fixes this issue. See if the 2.0.14pre5 tarball fixes this bug. See: http://www.inference.phy.cam.ac.uk/mcdavey/downloads/
Jerry, can you verify whether or not the 'pre5' tarball makes the backup conduit reliable for you?
Any update?
Matt, sorry for missing these updates. I'll test it soon.
Matt, I had a test using the 'pre5' tarball , it worked fine.
Excellent. Closing.