Bug 828846 - Evolution Segmentation fault after upgrade to F17
Evolution Segmentation fault after upgrade to F17
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-06-05 09:02 EDT by Jan "Yenya" Kasprzak
Modified: 2012-06-27 09:28 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-26 06:24:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot of calendar view (blur in the "task" area added by myself) (79.36 KB, image/png)
2012-06-20 06:42 EDT, Jan "Yenya" Kasprzak
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 678856 None None None 2012-06-26 06:24:41 EDT

  None (edit)
Description Jan "Yenya" Kasprzak 2012-06-05 09:02:05 EDT
Description of problem:
After upgrading my workstation from F16 to F17, evolution stopped working.
I have tried to run it from the command line instead of main menu to see the output: 

It tried to migrate my data to the new format (I don't have the exact message, though), complaining that $HOME/.evolution/tasks is not empty, and segfaulting afterwards.

I have removed the directory .evolution/tasks, and after that evolution printed that it tries to migrate the old data, followed by a segfault.

Subsequent runs of evolution just end with "Segmentation fault", so I think the migration has succeeded and the problem is somewhere later.

I am running XFCE session, not GNOME, FWIW.

Version-Release number of selected component (if applicable):

How reproducible:
100 % (in my environment)

Steps to Reproduce:
1. install F16, put some calendar data into evolution
2. upgrade to F17
3. run evolution from the command line
Actual results:
Segmentation fault

Expected results:
Evolution window should pop up

Additional info:
I use evolution mainly for calendar, not for e-mail.

Running strace -f evolution reveals that one of the threads crashes after reading /etc/localtime:
3870  stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2246, ...}) = 0
3870  open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 44
3870  fstat(44, {st_mode=S_IFREG|0644, st_size=2246, ...}) = 0
3870  fstat(44, {st_mode=S_IFREG|0644, st_size=2246, ...}) = 0
3870  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe40005b000
3870  read(44, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0\0\0"..., 4096) = 2246
3870  lseek(44, -1440, SEEK_CUR)        = 806
3870  read(44, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 1440
3870  lseek(44, 2245, SEEK_SET)         = 2245
3870  close(44)                         = 0
3870  munmap(0x7fe40005b000, 4096)      = 0
3870  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1c} ---
3873  +++ killed by SIGSEGV +++
3874  +++ killed by SIGSEGV +++
3872  +++ killed by SIGSEGV +++
3871  +++ killed by SIGSEGV +++
3870  +++ killed by SIGSEGV +++

Installing debuginfos (debuginfo-install evolution) and running evolution under gdb does not make evolution crash, but it does not display any window either. The gdb output (after hitting CTRL-C) is:

(gdb) r
Starting program: /usr/bin/evolution evolution
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe33f5700 (LWP 4231)]
[New Thread 0x7fffe1f3b700 (LWP 4232)]
[New Thread 0x7fffe173a700 (LWP 4233)]
[New Thread 0x7fffc7626700 (LWP 4234)]

(evolution:4228): evolution-shell-WARNING **: Cannot import any of the given URIs
[Thread 0x7fffc7626700 (LWP 4234) exited]
Program received signal SIGINT, Interrupt.
0x00007fffef32eeef in __GI___poll (fds=<optimized out>, nfds=<optimized out>, 
    timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
87	  int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);

Running evolution with "ulimit -c unlimited" and examining the core file shows the crash is indeed time zone related:

$ gdb evolution core.4414 
GNU gdb (GDB) Fedora (
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /usr/bin/evolution...Reading symbols from /usr/lib/debug/usr/bin/evolution.debug...done.
[New LWP 4414]
[New LWP 4415]
[New LWP 4416]
[New LWP 4420]
[New LWP 4423]
[New LWP 4418]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `evolution'.
Program terminated with signal 11, Segmentation fault.
#0  add_instance (comp=comp@entry=0x27939b0, start=start@entry=1338847200, 
    end=1338933600, data=data@entry=0x2942370) at e-cal-client.c:1311
1311				itt = icaltime_from_timet_with_zone (end, dtend.value->is_date, instances_hold->end_zone);
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-29.fc17.x86_64 [...]
(gdb) where
#0  add_instance (comp=comp@entry=0x27939b0 [ECalComponent], start=start@entry=
    1338847200, end=1338933600, data=data@entry=0x2942370)
    at e-cal-client.c:1311
#1  0x00007fb9e1d53cfa in generate_instances_for_chunk (cb_data=0x2942370, cb=
    0x7fb9e1d3a160 <add_instance>, convert_end_date=1, duration_seconds=0, 
    duration_days=1, chunk_end=0x7fff8e181a20, chunk_start=0x7fff8e181a10, 
    interval_start=1338760800, event_start=0x7fff8e1819f0, single_rule=0, 
    exdates=<optimized out>, exrules=<optimized out>, rdates=<optimized out>, 
    rrules=<optimized out>, zone=0x27378a0, comp_dtstart=1023228000, comp=
    0x27939b0 [ECalComponent]) at e-cal-recur.c:1392
#2  e_cal_recur_generate_instances_of_rule (comp=comp@entry=
    0x27939b0 [ECalComponent], prop=prop@entry=0x0, start=start@entry=
    1338760800, end=end@entry=1339192800, cb=cb@entry=
    0x7fb9e1d3a160 <add_instance>, cb_data=cb_data@entry=0x2942370, 
    tz_cb=tz_cb@entry=0x7fb9e1d43280 <e_cal_client_resolve_tzid_cb>, 
    default_timezone=default_timezone@entry=0x27378a0) at e-cal-recur.c:864
#3  0x00007fb9e1d5462f in e_cal_recur_generate_instances (comp=comp@entry=
    0x27939b0 [ECalComponent], start=start@entry=1338760800, end=end@entry=
    1339192800, cb=cb@entry=0x7fb9e1d3a160 <add_instance>, 
    cb_data=cb_data@entry=0x2942370, tz_cb=tz_cb@entry=
    0x7fb9e1d43280 <e_cal_client_resolve_tzid_cb>, tz_cb_data=tz_cb_data@entry=
    0x26c5480, default_timezone=default_timezone@entry=0x27378a0)
---Type <return> to continue, or q <return> to quit---
    at e-cal-recur.c:640
#4  0x00007fb9e1d436bc in generate_instances (client=0x26c5480 [ECalClient], 
    start=1338760800, end=1339192800, objects=objects@entry=0x293a690 = {...}, 
    cancellable=0x2920060 [GCancellable], cb=cb@entry=
    0x7fb9e1d3a160 <add_instance>, cb_data=cb_data@entry=0x29452b0)
    at e-cal-client.c:1561
#5  0x00007fb9e1d43da3 in generate_instances_for_object_got_objects_cb (goad=
    0x2945020, objects=0x293a690 = {...}) at e-cal-client.c:2027
#6  0x00007fb9e1d40882 in got_objects_for_uid_cb (
    source_object=<optimized out>, result=0x24a7c10, user_data=0x2945020)
    at e-cal-client.c:1745
#7  0x00007fb9df173e77 in g_simple_async_result_complete (simple=
    0x24a7c10 [GSimpleAsyncResult]) at gsimpleasyncresult.c:767
#8  0x00007fb9e0fbdff9 in finish_async_op (async_data=<optimized out>, error=
    0x0, in_idle=0) at e-client.c:2260
#9  0x00007fb9e0fc2a64 in async_result_ready_cb (source_object=
    0x25d8db0 [EGdbusCalProxy], result=0x2521000, user_data=0x2945140)
    at e-client.c:2297
#10 0x00007fb9df173e77 in g_simple_async_result_complete (simple=
    0x2521000 [GSimpleAsyncResult]) at gsimpleasyncresult.c:767
#11 0x00007fb9df173f79 in complete_in_idle_cb (data=<optimized out>)
    at gsimpleasyncresult.c:779
#12 0x00007fb9dd8266e5 in g_main_dispatch (context=0x1caa980) at gmain.c:2539
---Type <return> to continue, or q <return> to quit---
#13 g_main_context_dispatch (context=context@entry=0x1caa980) at gmain.c:3075
#14 0x00007fb9dd826a18 in g_main_context_iterate (context=0x1caa980, 
    block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at gmain.c:3146
#15 0x00007fb9dd826e12 in g_main_loop_run (loop=0x21aefe0) at gmain.c:3340
#16 0x00007fb9dfa6cd65 in gtk_main () at gtkmain.c:1161
#17 0x00000000004022da in main (argc=1, argv=0x7fff8e182108) at main.c:681

My /etc/localtime is the following:

$ ls -l /etc/localtime
-rw-r--r--. 1 root root 2246 Mar  6  2007 /etc/localtime
$ rpm -qf /etc/localtime
$ sha1sum /etc/localtime
dfe6e078c1c95953796854bc6fc176ed45bd9545  /etc/localtime

I am in the Central-European (CET/CETDST) time zone.
Comment 1 Milan Crha 2012-06-08 05:13:02 EDT
Thanks for a bug report. I do not expect the local timezone being an issue. This is crashing later in the code.

could you print values of these variables, please:
I suppose one of them is NULL, most likely dtend.value or instances_hold.

Will evolution start in mailer if you run it there, please? You can do that by running evolution from console as this:
   $ evolution -c mail
It should run, because the crashing operation is invoked from Calendar view.
Comment 2 Jan "Yenya" Kasprzak 2012-06-20 06:41:07 EDT
In the meantime, I have upgraded evolution from the updates repository (to evolution-3.4.2-1.fc17.x86_64). It now displays the calendar, but the window is only partly drawn, and large areas are black. I will attach the screenshot.

After few seconds of usage (switching to the next and previous weeks), it has crashed nevertheless. From the variables mentioned in comment #1, two are NULL:

(gdb) print end
$1 = 1339797600
(gdb) print dtend.value
$2 = (struct icaltimetype *) 0x0
(gdb) print instances_hold
$3 = (struct instances_info *) 0x222fc80
(gdb) print instances_hold->end_zone
$4 = (icaltimezone *) 0x0

"evolution -c mail" works fine, but I don't have any mail accounts configured. I have tested that creating new mail pops up an editor window, the pull-down menu works correctly, etc.
Comment 3 Jan "Yenya" Kasprzak 2012-06-20 06:42:46 EDT
Created attachment 593174 [details]
Screenshot of calendar view (blur in the "task" area added by myself)
Comment 4 Milan Crha 2012-06-26 06:24:41 EDT
The black parts are supposed to be gray, I guess it's because of your Theme, evolution didn't read its colors properly, and defaulted into the black color (or is it a color your XFCE color theme?).

Nonetheless, back to the crash, I moved it upstream as [1]. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions.

I guess the issue with the theming can be also filled rather upstream, as it doesn't seem to be Fedora specific issue.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=678856
Comment 5 Jan "Yenya" Kasprzak 2012-06-26 06:39:00 EDT
OK, thanks for forwarding the bug upstream. I have added myself as Cc: to the upstream bug.

As for the colors - I don't think I use anything non-standard: the menus and the whole mail mode are displayed correctly. However, I have just tested on another F17 machine, where I don't use evolution (so presumably there is a default configuration), that the black areas are not there in a calendar view. So this _might_ be something with my local settings.
Comment 6 Milan Crha 2012-06-27 08:40:09 EDT
Is the other machine running XFCE too? I think this is because non-gnome environment too.
Comment 7 Jan "Yenya" Kasprzak 2012-06-27 08:52:27 EDT
Sorry for not mentioning that. Yes, the other machine is running XFCE as well. I don't use GNOME since the 3.0 thing.
Comment 8 Milan Crha 2012-06-27 09:28:44 EDT
Hmm, I see. That's interesting. Maybe if you could open a new bug report upstream, thus it's not forgotten about it, though if one machine works as expected and another not, then I'm afraid it'll be pretty hard to debug.

Note You need to log in before you can comment on or make changes to this bug.