tags 744078 + moreinfo reassign 744078 libfolks-eds25 found 744078 0.9.6-2 thanks
I think this is most likely to be a Folks bug; reassigning. On 09/04/14 20:57, Guilhem Bonnefille wrote: > Core was generated by `empathy'. > Program terminated with signal 11, Segmentation fault. > #0 0x00007f2c22793bd4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > (gdb) where > #0 0x00007f2c22793bd4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #1 0x00007f2c227966c9 in g_date_time_to_timezone () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x00007f2c2279673c in g_date_time_to_utc () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x00007f2bf54aa302 in _edsf_persona_update () > from /usr/lib/x86_64-linux-gnu/libfolks-eds.so.25 > #4 0x00007f2bf54ab9fe in ?? () > from /usr/lib/x86_64-linux-gnu/libfolks-eds.so.25 > #5 0x00007f2c22a7f2e4 in ?? () > from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 I can't reproduce this crash. Please install debugging symbols for at least GLib and folks (packages: libglib2.0-0-dbg, libfolks-eds-dbg, libfolks-dbg) and try to get a backtrace again. Using the gdb command "thread apply all bt full" instead of "where" might also provide useful information. You can probably see this crash without Empathy by installing folks-tools and running folks-inspect. If it doesn't crash immediately, wait a few seconds; if it still hasn't crashed, type "individuals" at the prompt and see whether that crashes. If folks-inspect crashes, then it's confirmed to be a Folks bug. Upgrading libfolks25, libfolks-eds25 and related packages to the version from unstable (0.9.6-3) might also be useful. If you run empathy from a command-line (gnome-terminal or similar), do you get any warnings before it crashes? What accounts (local? Google? Owncloud? Facebook? etc.) do you have configured in evolution-data-server? > Seems related to an arch bug: > https://bugs.archlinux.org/task/39200?string=glib&project=1&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom= That looks as though it could be the same bug. However, the Arch bug helpfully says "In the internet it is stated that..." and "Since this is stated to be fixed in 0.9.7..." without providing any links or upstream bug references. Folks 0.9.7 doesn't actually exist yet; if there's a fix for this in the upstream git repository (which might have confused the Arch bug submitter by being marked as "will be fixed in 0.9.7"), then we can cherry-pick it, but I can't find anything obviously related to this crash. Looking at the source code, the only to_utc() calls I can see are here: var d = new DateTime (Persona._local_time_zone, (int) bday.year, (int) bday.month, (int) bday.day, 0, 0, 0.0); if (this._birthday == null || (this._birthday != null && !((!) this._birthday).equal (d.to_utc ()))) { this._birthday = d.to_utc (); this.notify_property ("birthday"); } so the only way I can see for that to crash is if d was NULL, which could happen if one of bday.year, bday.month, bday.day is out-of-range. Do you have any contacts whose birthday (as seen in Evolution) is an impossible date like 2000-02-31? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org