GNOME Bugzilla – Bug 442329
Todo conduit hangs indefinitely on tasks without due date copied *from* PDA
Last modified: 2013-09-13 12:34:22 UTC
Steps to reproduce: 1. Create task without due date/empty date on the PDA 2. Synchronize or "Copy from PDA" Stack trace: (gdb) cont Continuing. [New Thread -1277781104 (LWP 9610)] Program received signal SIGABRT, Aborted. [Switching to Thread -1226258752 (LWP 9141)] 0xffffe410 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 136818
Other information: Copying tasks with empty due date *to* the PDA works fine.
See also https://bugs.launchpad.net/ubuntu/+source/gnome-pilot-conduits/+bug/81170 in Ubuntu. Lots of people seem to have this problem. The problem did not occur in previous versions of Ubuntu.
Thanks for forwarding this bug. Shame it took so long for the bug to be notified upstream! I'll notify the developers who work on the evo conduits. This bug is well described, and appears to be easily reproducible (although I haven't tried yet). In the meantime, it would be handy if you could provide a debug backtrace.
(In reply to comment #2) > This bug is well described, and appears to be easily reproducible (although I > haven't tried yet). In the meantime, it would be handy if you could provide a > debug backtrace. Isn't the one I posted already a debug backtrace? I installed the gnome-pilot-conduits-dbg package and used gdb as described on the GettingTraces page. Do I need some other dbg package or do something different in gdb?
I am willing to gather data to help solve this problem as well. In the spirit of such I have grabbed an strace of gpilotd syncing with my palm. I confirm it writes "Dated" todo's no problem, but when it reaches the first one without a date it dies. And something interesting in the trace: Excerpt from strace which I have attached to the case: write(2, "etodoconduit-Message: add_record"..., 189etodoconduit-Message: add_record: adding [0 1183089600 3 0 'pick an exterminator and call them' '' 11] to desktop ) = 189 [... Do a whole bunch of USBDEVFS Stuff ...] write(2, "etodoconduit-Message: add_record"..., 107etodoconduit-Message: add_record: adding [1 -1 3 0 'Brainstorm: Customer communication' '' 11] to desktop ) = 107 time(NULL) = 1182529355 time(NULL) = 1182529355 getppid() = 24715 getgid32() = 1000 open("/dev/tty", O_RDWR|O_NONBLOCK|O_NOCTTY) = 25 writev(25, [{"*** stack smashing detected ***:"..., 33}, {"gpilotd", 7}, {" terminated\n", 12}], 3*** stack smashing detected ***: gpilotd terminated ) = 52 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(24717, 24717, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- +++ killed by SIGABRT (core dumped) +++ So the first record had a date field, the second one didn't and you can see something curious, it tries to open /dev/tty on this one. Which is strange since I am not using /dev/tty but the USB stuff. Going to do a bit more digging when I get a chance. But possibly this is related?
Created attachment 90463 [details] strace of crash Here is the aforementioned strace.
Hi! I can confirm the same behaviour, with the same test case. After digging a bit into the code of evolution, I could identify that the problem is caused in comp_from_remote_record() in todo-conduit.c, by todo.due being completely garbage when no due date is filled in the task on the PDA side. So I assume we should test todo.indefinite before using a possible non-significant todo.due struct. A comment in the code of unpack_ToDo() from pilot-link-0.12.1 confirms that todo->due in invalid when todo->indefinite is set to 1. See redhat bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249640 for a possible patch that works for me.
Thanks for this, Fabrice. Sounds like the culprit. I've added a comment to https://bugs.launchpad.net/ubuntu/+source/gnome-pilot-conduits/+bug/81170 asking for any success reports, so we can get this adopted asap.
I have applied the patch to detailed on the redhat bugzilla and rebuilt the deb for 2.10.1 on feisty. And it is now working fine. I was able to sync up about 200 tasks about 150 or so of them with non due-date with my palm tungsten e.
Assigning to Evolution->conduits. Evo team: please see the simple patch in the redhat bugzilla ticket: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249640 This fixes a crash in the todo conduit due to an unitialised due-date field.
Btw, this problem doesn't persist for me in g-p 2.0.15 / evo 2.12.0. I can copy tasks without due date from and to PDA having no problems.
I should have checked the source! Looks like this issue was fixed in Evo 2.11.92+ or 2.12.x.
Closing as per last comment.