On Mon, 2010-05-24 at 15:24 +0100, Frederik Elwert wrote: > Am Sonntag, den 23.05.2010, 22:05 +0200 schrieb Patrick Ohly: > > Yes, there's one more thing that you can do: when it crashes, what's at > > the end of the log in .cache? > > > > I think it I know why it crashes (null pointer for system time zone > > information), I just don't know why it doesn't find any. The log might > > explain that. > > Unfortunately, there is no log in .cache, not even a directory, it > seems. Maybe it crashes before it even has the log file in place?
Perhaps the version that I had compiled didn't have the logging enabled at that point. Anyway, I think I was able to reproduce and fix the problem that you were seeing: commit b4865677f5330b6b844190cacec794f1bfb3d380 Author: Patrick Ohly <[email protected]> Date: Wed May 26 18:44:04 2010 +0200 syncevo-dbus-server: first sync was done without libical time zone info (MBC #2435) If (and only if) compiled with --enable-evolution-compatibility (as the binaries on syncevolution.org), libical was only pulled into the syncevo-dbus-server as part of running a sync. That was too late for libsynthesis, which had already checked for libical earlier in that sync session. All following sync sessions then used libical time zone information. The effect of not having libical time zone information were occasional mismatches of time zones. I have compiled another snapshot (version 1.0beta3+20100526+SE+b486567 +SYSYNC+a0b96cb) and made it available here: http://downloads.syncevolution.org/tmp If you want, upgrade to that one. Because it you were not able to reproduce it reliably (no surprise, given that it only occurs when synchronizing events directly in the first session after starting the daemon, and then probably only for some time zone definitions) I don't expect you to confirm that the problem is gone. But if you run that version *and* it still occurs, then I need log files and will keep searching. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
