GNOME Bugzilla – Bug 588487
Crash in icalrecur_iterator_next, e_cal_recur_generate_instances_of_rule at e-cal-recur.c line 720
Last modified: 2011-03-16 14:54:38 UTC
Version: 2.28.x What were you doing when the application crashed? I just upgraded evo & friends to today's git master (along with several other gnome applications, including gnome-themes). I'd just done an evolution --force-shutdown and restarted. The mail gui mapped and here we are. One other thing: I had to configure evolution without networkmanager support Distribution: Slackware Slackware 12.2.0 Gnome Release: 2.27.3 2009-06-16 (GARNOME) BugBuddy Version: 2.27.1 System: Linux 2.6.30 #36 SMP PREEMPT Wed Jun 10 11:08:08 EDT 2009 i686 X Vendor: The X.Org Foundation X Vendor Release: 10699001 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome GTK+ Modules: gnomebreakpad Memory status: size: 88268800 vsize: 88268800 resident: 12574720 share: 10301440 rss: 12574720 rss_rlim: 18446744073709551615 CPU usage: start_time: 1247521905 rtime: 23 utime: 21 stime: 2 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/garnome-svn-2.27/libexec/evolution/2.28/evolution-alarm-notify' [Thread debugging using libthread_db enabled] [New Thread 0xb60d0700 (LWP 14617)] [New Thread 0xb0bffb90 (LWP 14645)] [New Thread 0xb5df0b90 (LWP 14618)] 0xb61bb01d in poll () from /lib/libc.so.6
+ Trace 216416
Thread 2 (Thread 0xb0bffb90 (LWP 14645))
----------- .xsession-errors (367714267 sec old) --------------------- iceauth: creating new authority file /home/ronis/.ICEauthority --------------------------------------------------
looks related to bug 554283
(In reply to comment #1) > looks related to bug 554283 > Seems like the very similar issue. David, when does it happen? When running in calendar component, in some particular view, or any other way how to reproduce? I guess it'll need those events too, the same day run and such.
I was in the mail component. As to reproducing this. It hasn't happened today (I think).
*** Bug 588712 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > I was in the mail component. As to reproducing this. It hasn't happened today > (I think). Oh, I overlooked, this is evolution-alarm-notify crash. What are your calendar types you've selected for alarm notifications? (Edit->Preferences->Calendar and Tasks->tab Alarms)
I've got all the calendars selected (dumb); this includes, 5 local calendars, 1 mapi calandar,, birthdays & anniversaries (local), weather, and 1 web based calendar.
Created attachment 138546 [details] VCARD entry associated with the crash I modified the hostnames that appear in the vcard. This has been recurring every Monday at 8:00PM since 2006-09-11. Note that the hostnames on the UID: and X-EVOLUTION-ALARM-UID: lines differ.
hrm, I imported it to my local calendar, changed few things like the timezone to the old one, then removed a recurrence-id to have it recur, but no, when the alarm is triggered, it works. I guess same as for you mostly. I'll try to work with this for some time, but I doubt a bit it'll be triggered. Let's see.
OK, after an update to libical of revision 938 it crashes here too, though slightly different place (see below). Reverting to revision 932 (which is the one I used in the previous test) doesn't crash evolution. I sent them an email to [1]. I would suggest to downgrade libical until this will be sorted out. [1] http://sourceforge.net/mailarchive/forum.php?forum_name=freeassociation-devel
+ Trace 216539
I can confirm; reverting fixes the problem, and also fixes the problem I reported with tooltips in Bug 588805
*** Bug 588805 has been marked as a duplicate of this bug. ***
since libical offers a testsuite in src/test/ which iterates through the data in test-data, could you offer a test that reproduces this bug? or does it crash with one of the current tests?
I restored the head branch, rebuilt, and ran make check. Here's what I get (skipping build stuff): 1.. ########## Test time parser functions (1) ########## ok 1 - 19970101T1000 is null time ok 2 - 19970101X100000 is null time ok 3 - 19970101T100000 is valid Wed Jan 1 10:00:00 1997 ok 4 - 19970101T100000Z is valid Wed Jan 1 10:00:00 1997 ok 5 - 19970101 is valid Wed Jan 1 00:00:00 1997 ########## Test time (2) ########## ---> From time_t Orig : 2002-06-26 21:44:29 Z icaltime_from_timet(tt,0) (DEPRECATED) ok 6 - icaltime_from_timet(1025127869) as UTC ok 7 - Floating time from time_t ok 8 - icaltime_from_timet_with_zone(tt,0,zone) as zone ok 9 - icaltime_from_timet_with_zone(tt,0,utc) ---> Convert from floating ok 10 - Convert from floating to UTC ok 11 - Convert from floating to zone ---> Convert from UTC ok 12 - Convert from UTC to UTC ok 13 - Convert from UTC to zone (test year/mon only..) No conversion: 2002-06-26 21:44:29 Z ok 14 - No conversion at all (test year/mon only) Back to UTC : 2002-06-26 21:44:29 Z ok 15 - test time conversion routines ---> Convert from zone To zone : 2002-06-26 21:44:29 (floating) To UTC : 2002-06-26 21:44:29 Z UTC No conversion: 2002-06-26 21:44:29 Z Back to zone : 2002-06-26 21:44:29 Z ok 16 - test time conversion, round 2 ok 17 - test icaltime -> time_t for 20001103T183030Z Normalize Orig (ical) : 2000-11-03 18:30:30 Z UTC -5d in sec : 2000-10-29 18:30:30 Z UTC +60 d : 2000-12-28 18:30:30 Z UTC As time_t 20001103T183030Z (timet): 2000-11-03 18:30:30 Z 20001103T183030Z : 2000-11-03 18:30:30 Z UTC ok 18 - test normalization 20001103T183030 (timet): 2000-11-03 18:30:30 Z 20001103T183030 : 2000-11-03 18:30:30 (floating) offset_tz : 0 ok 19 - test utc offset As local : 2000-11-03 18:30:30 Z UTC Convert to and from lib c System time is: 2000-11-03 18:30:30 Z System time from libical: 20001103T183030Z Converted back to libc: 2000-11-03 18:30:30 Z Incrementing time Add a year: 2001-11-03 18:30:30 Z Add 13 months: 1969-12-31 23:59:59 Z Add 90 seconds: 1969-12-31 23:59:59 Z Day Of week ok 20 - Testing day of week 6 ok 21 - Testing day of year 308 ok 22 - Week started on doy of 303 TimeZone Conversions /bin/sh: line 4: 12584 Segmentation fault (core dumped) ${dir}$tst FAIL: regression Australia/Perth: day 297: first failed: libc 2009-10-25 12:00:00 dst 0 != libical 2009-10-25 13:00:00 dst 1 Australia/Eucla: day 297: first failed: libc 2009-10-25 12:00:00 dst 0 != libical 2009-10-25 13:00:00 dst 1 *** Summary: 401 zones tested, 136 days failed, 146229 okay => 0% failed *** FAIL: timezones =============================================== 2 of 2 tests failed Please report to http://freeassociation.sf.net/ =============================================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/ronis/Project/notar/GNOME/garnome/svn/libical/work/main.d/libical-svn/src/test'
There have been many fixes lately in libical, mainly security fixes. This was one of the side effects, I didn't runt the test. I have fixed it in upstream, please check if it fixes the problem. rev 939
Wilfried, libical-0.43 was released ~6 months ago. good time to make a new release now that many fixes have gone in?
Created attachment 138917 [details] Results of make check for version 939 In short, there are still 2 testsuite failures.
Followup to Comment #16. If I install the lib and restart evolution, I still get the wrong times in the tooltips. Whatever was fixed, seems to have missed something.
Fixed on rev940
With 940 I still find: Australia/Perth: day 297: first failed: libc 2009-10-25 12:00:00 dst 0 != libical 2009-10-25 13:00:00 dst 1 Australia/Eucla: day 297: first failed: libc 2009-10-25 12:00:00 dst 0 != libical 2009-10-25 13:00:00 dst 1 *** Summary: 401 zones tested, 136 days failed, 146229 okay => 0% failed *** FAIL: timezones =============================================== 1 of 2 tests failed Calendar Tooltips are behaving properly again.
I just upgraded to 940 on another box, this time running 'make check' and logging the results. I noticed that my report in Comment #19 missed many of the failures. I'll attach the log
Created attachment 139097 [details] Log of make check for version 940
(In reply to comment #20) Yes, there are some test that are failing. But now it passes more that 0.43. Some of the tests are failing because they are using the builtin tzinfo (it should be updated) and others I have checked I think the test is wrong. I will probably start looking at them in the future. But IMHO they are not related to this bug ;) (and others probably fail for a good reason)
bug #572516 comment #6 has the reasons why some of the timezone checks fail
I'm closing this after seeing the backlog, all was related to particular version of libical. libical-0.46, released on 2010-08-30, may have most issues fixed, at least this crasher.