Re: [Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535
On Mon, 2011-02-21 at 14:08 +0100, Carlos Martín Nieto wrote: On Thu, 2011-02-17 at 08:21 +0100, Milan Crha wrote: On Thu, 2011-02-17 at 00:48 +0100, Carlos Martín Nieto wrote: I've attached the backtrace for a year of 167 (I think) though I don't think it gives much information. This happens even if I have my main calendar off (which I think it's the only one with recurring events). Hi, this is from your CalDAV calendar, based on the backtrace. Try to get the component which is causing this trouble, and see whether there is something wrong either with that component or with evolution. You can achieve that if you breakpoint as you did earlier, then move to frame of e_cal_backend_sexp_match_comp function and invoke gdb command: (gdb) printf %s\n, e_cal_component_get_as_string (comp) then strip any private information (the best by replacing with 'x' or similar letter) and maybe share it here, if you think it's correct, or better file a bug report and post here a link to it. I'm not sure whose fault it is, but the RRULE:FREQ=WEEKLY;UNTIL=20110219;INTERVAL=-1;BYDAY=WE line looks suspicous. I've checked on the Google Calendar and even there it says it repeats each -1 weeks :S So I'm going to write up a patch to ignore intervals 0 (maybe 1 better?) Hi Carlos, From RFC5545: The INTERVAL rule part contains a positive integer representing at which intervals the recurrence rule repeats. The default value is 1, meaning every second for a SECONDLY rule, every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule, and every year for a YEARLY rule. For example, within a DAILY rule, a value of 8 means every eight days. So yes: 0 is also invalid, as you would expect :-) Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN To be is to program. signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535
On Tue, 2011-02-22 at 11:30 +1300, Andrew McMillan wrote: [...] Hi Carlos, From RFC5545: The INTERVAL rule part contains a positive integer representing at which intervals the recurrence rule repeats. The default value is 1, meaning every second for a SECONDLY rule, every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule, and every year for a YEARLY rule. For example, within a DAILY rule, a value of 8 means every eight days. So yes: 0 is also invalid, as you would expect :-) A very reasonable thing for the RFC to say :) This should probably be done in libical, but within e-d-s it the following patch probably makes more sense than the one I posted on the other thread (Deal with negative intervals) [PATCH] ECalRecur: Convert negative intervals into the default (1) Negative intervals have been spotted in the wild. An interval lower than 1 doesn't make any sense, so if we see one, we replace it by the default iCal interval of 1. --- calendar/libecal/e-cal-recur.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/calendar/libecal/e-cal-recur.c b/calendar/libecal/e-cal-recur.c index 3c30618..9eda66a 100644 --- a/calendar/libecal/e-cal-recur.c +++ b/calendar/libecal/e-cal-recur.c @@ -996,7 +996,8 @@ e_cal_recur_from_icalproperty (icalproperty *prop, gboolean exception, ir = icalproperty_get_rrule (prop); r-freq = ir.freq; - r-interval = ir.interval; + /* Interval 1 doesn't make sense, so use the default. */ + r-interval = ir.interval 1 ? 1 : ir.interval; r-enddate = e_cal_recur_obtain_enddate (ir, prop, zone, convert_end_date); -- Carlos Martín Nietohttp://www.cmartin.tk ¿Cómo voy a decir bobadas si soy mudo? -- CACHAI signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535
Hi all, I'm running evo master, and I've been getting weird messages, about the year being below 1900 (the assert in libecal's time_days_in_month(). I've put a g_print() statement to print the year on each run. The messages scroll too fast for me to see each one, but I could see the years counting down from ~2000 to what I paste below. I've attached the backtrace for a year of 167 (I think) though I don't think it gives much information. This happens even if I have my main calendar off (which I think it's the only one with recurring events). Any hints as to what should be investigated next? --8-8 (e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month: assertion `year = 1900' failed Year: 0 (e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month: assertion `year = 1900' failed Year: 0 (e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month: assertion `year = 1900' failed Year: 65535 (e-calendar-factory:22846): libecal-WARNING **: time_t out of range Year: 2011 Year: 2011 cmn -- Carlos Martín Nietohttp://www.cmartin.tk ¿Cómo voy a decir bobadas si soy mudo? -- CACHAI #0 0xf7700425 in __kernel_vsyscall () #1 0xf686801b in write () at ../sysdeps/unix/syscall-template.S:82 #2 0xf672cd66 in write_string (fd=2, string=0x930c7f0 \n(e-calendar-factory:22846): libecal-CRITICAL **: time_days_in_month: assertion `year = 1900' failed\n) at gmessages.c:140 #3 0xf672d10f in g_log_default_handler (log_domain=0xf76f6b14 libecal, log_level=value optimized out, message=0x930c7b8 time_days_in_month: assertion `year = 1900' failed, unused_data=0x0) at gmessages.c:998 #4 0xf672d515 in g_logv (log_domain=0xf76f6b14 libecal, log_level=G_LOG_LEVEL_CRITICAL, format=0xf679c0b8 %s: assertion `%s' failed, args1=0xffe1040c \220\237o\367Ҟo\367\020) at gmessages.c:527 #5 0xf672d992 in g_log (log_domain=0xf76f6b14 libecal, log_level=G_LOG_LEVEL_CRITICAL, format=0xf679c0b8 %s: assertion `%s' failed) at gmessages.c:577 #6 0xf672db8d in g_return_if_fail_warning (log_domain=0xf76f6b14 libecal, pretty_function=0xf76f9f90 time_days_in_month, expression=0xf76f9ed2 year = 1900) at gmessages.c:586 #7 0xf76e5587 in time_days_in_month (year=167, month=3) at e-cal-time-util.c:450 #8 0xf76dfe89 in cal_obj_time_add_days (cotime=0xffe10920, days=value optimized out) at e-cal-recur.c:3424 #9 0xf76e08e3 in cal_obj_weekly_find_next_position (cotime=0xffe10920, event_end=0xffe10928, recur_data=0xffe10544, interval_end=0xffe10b04) at e-cal-recur.c:2299 #10 0xf76e28e4 in cal_obj_expand_recurrence ( event_start=value optimized out, zone=value optimized out, recur=0x92e6858, interval_start=0xffe10b0c, interval_end=0xffe10b04, finished=0xffe10b4c) at e-cal-recur.c:1589 #11 0xf76e3aba in generate_instances_for_chunk (comp=value optimized out, prop=value optimized out, start=1297638000, end=129807, cb=0xf66b5b60 check_instance_time_range_cb, cb_data=0x92f6210, tz_cb=0xf66b61c0 resolve_tzid, tz_cb_data=0x92f6210, default_timezone=0xf546b0f0) at e-cal-recur.c:1186 #12 e_cal_recur_generate_instances_of_rule (comp=value optimized out, prop=value optimized out, start=1297638000, end=129807, cb=0xf66b5b60 check_instance_time_range_cb, cb_data=0x92f6210, tz_cb=0xf66b61c0 resolve_tzid, tz_cb_data=0x92f6210, default_timezone=0xf546b0f0) at e-cal-recur.c:865 #13 0xf66b6daf in func_occur_in_time_range (esexp=0x92fb6b0, argc=2, argv=0xffe10be0, data=0x92f6210) at e-cal-backend-sexp.c:390 #14 0xf668f6c3 in e_sexp_term_eval (f=0x92fb6b0, t=0x92fc2c0) at e-sexp.c:731 #15 0xf6690060 in term_eval_and (f=0x92fb6b0, argc=2, argv=0x92fc430, data=0xf669f080) at e-sexp.c:271 #16 0xf668f79b in e_sexp_term_eval (f=0x92fb6b0, t=0x92fc1d0) at e-sexp.c:721 #17 0xf668f83d in e_sexp_eval (f=0x92fb6b0) at e-sexp.c:1568 #18 0xf66b763e in e_cal_backend_sexp_match_comp (sexp=0xf546bd50, comp=0x9258130, backend=0x9227210) at e-cal-backend-sexp.c:1323 #19 0xf5ee644a in caldav_start_query (backend=0x9227210, query=0x9219218) at e-cal-backend-caldav.c:4196 #20 0xf66b0f98 in e_cal_backend_start_query (backend=0x9227210, query=0x9219218) at e-cal-backend.c:818 #21 0xf66c5bd6 in impl_DataCalView_start (object=0x9215730, invocation=0x92cd3b0, query=0x9219218) at e-data-cal-view.c:314 #22 0xf76f6964 in _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT ( closure=0x92f9d98, return_value=0xffe10f64, n_param_values=2, param_values=0x922e800, invocation_hint=0xffe10f50, marshal_data=0xf66c5b50) at e-gdbus-marshallers.c:202 #23 0xf68e79f2 in g_closure_invoke (closure=0x92f9d98, return_value=0xffe10f64, n_param_values=2, param_values=0x922e800, invocation_hint=0xffe10f50) at gclosure.c:767 #24 0xf690118d in signal_emit_unlocked_R (node=value optimized out, detail=value optimized out, instance=0x9215730,
Re: [Evolution-hackers] Evolution requesting info on every year from 2011 down to 65535
On Thu, 2011-02-17 at 00:48 +0100, Carlos Martín Nieto wrote: I've attached the backtrace for a year of 167 (I think) though I don't think it gives much information. This happens even if I have my main calendar off (which I think it's the only one with recurring events). Hi, this is from your CalDAV calendar, based on the backtrace. Try to get the component which is causing this trouble, and see whether there is something wrong either with that component or with evolution. You can achieve that if you breakpoint as you did earlier, then move to frame of e_cal_backend_sexp_match_comp function and invoke gdb command: (gdb) printf %s\n, e_cal_component_get_as_string (comp) then strip any private information (the best by replacing with 'x' or similar letter) and maybe share it here, if you think it's correct, or better file a bug report and post here a link to it. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
