[Pkg-telepathy-maintainers] Bug#744078: Bug#744078: empathy: Empathy crashes at start

[Simon McVittie]

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