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): evolution-3.4.1-2.fc17.x86_64 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] ^C 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 (7.4.50.20120120-42.fc17) 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: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/evolution...Reading symbols from /usr/lib/debug/usr/bin/evolution.debug...done. 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>, tz_cb_data=tz_cb_data@entry=0x26c5480, 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 glibc-2.15-37.fc17.x86_64 glibc-2.15-37.fc17.i686 $ sha1sum /etc/localtime dfe6e078c1c95953796854bc6fc176ed45bd9545 /etc/localtime I am in the Central-European (CET/CETDST) time zone.
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: end dtend.value dtend.value->is_date instances_hold instances_hold->end_zone 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.
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.
Created attachment 593174 [details] Screenshot of calendar view (blur in the "task" area added by myself)
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
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.
Is the other machine running XFCE too? I think this is because non-gnome environment too.
Sorry for not mentioning that. Yes, the other machine is running XFCE as well. I don't use GNOME since the 3.0 thing.
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.