After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 588487 - Crash in icalrecur_iterator_next, e_cal_recur_generate_instances_of_rule at e-cal-recur.c line 720
Crash in icalrecur_iterator_next, e_cal_recur_generate_instances_of_rule at e...
Status: RESOLVED NOTGNOME
Product: evolution
Classification: Applications
Component: BugBuddyBugs
2.28.x (obsolete)
Other All
: High critical
: ---
Assigned To: Evolution Triage Team
Evolution QA team
: 588712 588805 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-07-13 21:54 UTC by David Ronis
Modified: 2011-03-16 14:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
VCARD entry associated with the crash (1.16 KB, text/plain)
2009-07-16 17:15 UTC, David Ronis
Details
Results of make check for version 939 (140.32 KB, text/plain)
2009-07-21 15:35 UTC, David Ronis
Details
Log of make check for version 940 (181.48 KB, text/plain)
2009-07-23 18:42 UTC, David Ronis
Details

Description David Ronis 2009-07-13 21:54:34 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

Thread 2 (Thread 0xb0bffb90 (LWP 14645))

  • #0 waitpid
    from /lib/libpthread.so.0
  • #1 IA__g_spawn_sync
    at gspawn.c line 382
  • #2 IA__g_spawn_command_line_sync
    at gspawn.c line 694
  • #3 run_bug_buddy
    at gnome-breakpad.cc line 369
  • #4 bugbuddy_segv_handle
    at gnome-breakpad.cc line 440
  • #5 <signal handler called>
  • #6 icalrecur_iterator_next
    at icalrecur.c line 2332
  • #7 icaltimezone_expand_vtimezone
    at icaltimezone.c line 693
  • #8 icaltimezone_ensure_coverage
    at icaltimezone.c line 526
  • #9 icaltimezone_get_utc_offset
    at icaltimezone.c line 834
  • #10 icaltimezone_convert_time
    at icaltimezone.c line 789
  • #11 icaltime_as_timet_with_zone
    at icaltime.c line 409
  • #12 e_cal_recur_generate_instances_of_rule
    at e-cal-recur.c line 720
  • #13 e_cal_util_generate_alarms_for_comp
    at e-cal-util.c line 596
  • #14 e_cal_get_alarms_for_object
    at e-cal.c line 4002
  • #15 query_objects_changed_async
    at alarm-queue.c line 736
  • #16 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #17 g_thread_create_proxy
    at gthread.c line 635
  • #18 start_thread
    from /lib/libpthread.so.0
  • #19 clone
    from /lib/libc.so.6


----------- .xsession-errors (367714267 sec old) ---------------------
iceauth:  creating new authority file /home/ronis/.ICEauthority
--------------------------------------------------
Comment 1 Akhil Laddha 2009-07-14 04:17:21 UTC
looks related to bug 554283 
Comment 2 Milan Crha 2009-07-15 17:16:04 UTC
(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.
Comment 3 David Ronis 2009-07-15 17:29:44 UTC
I was in the mail component.  As to reproducing this.  It hasn't happened today (I think).

Comment 4 Philip Withnall 2009-07-16 06:35:28 UTC
*** Bug 588712 has been marked as a duplicate of this bug. ***
Comment 5 Milan Crha 2009-07-16 09:14:32 UTC
(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)
Comment 6 David Ronis 2009-07-16 14:57:51 UTC
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.
Comment 7 David Ronis 2009-07-16 17:15:58 UTC
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.
Comment 8 Milan Crha 2009-07-17 10:24:40 UTC
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.
Comment 9 Milan Crha 2009-07-20 12:50:52 UTC
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


  • #7 <signal handler called>
  • #8 icalrecur_iterator_next
    at icalrecur.c line 2332
  • #9 adjust_dtstart_day_to_rrule
    at icaltz-util.c line 274
  • #10 icaltzutil_fetch_timezone
    at icaltz-util.c line 441
  • #11 icaltimezone_load_builtin_timezone
    at icaltimezone.c line 1819
  • #12 icaltimezone_get_tzid
    at icaltimezone.c line 1173
  • #13 e_cal_match_location
    at e-cal-check-timezones.c line 43
  • #14 e_cal_match_tzid
    at e-cal-check-timezones.c line 112
  • #15 e_cal_get_timezone
    at e-cal.c line 4740

Comment 10 David Ronis 2009-07-20 17:17:43 UTC
I can confirm; reverting fixes the problem, and also fixes the problem I reported with tooltips in Bug 588805
Comment 11 Milan Crha 2009-07-20 17:23:03 UTC
*** Bug 588805 has been marked as a duplicate of this bug. ***
Comment 12 Wilfried Goesgens 2009-07-20 19:29:27 UTC
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?
Comment 13 David Ronis 2009-07-20 20:08:24 UTC
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'
Comment 14 Alvaro Manera 2009-07-21 07:59:51 UTC
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
Comment 15 Suman Manjunath 2009-07-21 08:26:43 UTC
Wilfried, 

libical-0.43 was released ~6 months ago. good time to make a new release now that many fixes have gone in?
Comment 16 David Ronis 2009-07-21 15:35:39 UTC
Created attachment 138917 [details]
Results of make check for version 939

In short, there are still 2 testsuite failures.
Comment 17 David Ronis 2009-07-21 15:38:47 UTC
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.
Comment 18 Alvaro Manera 2009-07-23 08:11:10 UTC
Fixed on rev940
Comment 19 David Ronis 2009-07-23 17:12:23 UTC
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.
Comment 20 David Ronis 2009-07-23 18:41:39 UTC
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
Comment 21 David Ronis 2009-07-23 18:42:28 UTC
Created attachment 139097 [details]
Log of make check for version 940
Comment 22 Alvaro Manera 2009-07-24 06:36:17 UTC
(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)
Comment 23 Suman Manjunath 2009-07-25 04:18:25 UTC
bug #572516 comment #6 has the reasons why some of the timezone checks fail
Comment 24 Milan Crha 2011-03-16 14:54:38 UTC
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.