Bug 491755 – EDS crashed at start up

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 491755 - EDS crashed at start up


Summary:	EDS crashed at start up


Status:	RESOLVED FIXED

Product:	evolution-data-server
Classification:	Platform
Component:	Calendar
Version:	2.22.x (obsolete)
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	---
Assigned To:	Milan Crha
QA Contact:	Evolution QA team

URL:
Whiteboard:

Duplicates:	548396 (view as bug list)
Depends on:
Blocks:

Reported:	2007-10-30 14:56 UTC by Akhil Laddha
Modified:	2009-04-27 10:19 UTC

See Also:
GNOME target:	---
GNOME version:	2.19/2.20

Attachments
patch in e-cal-util.c (419 bytes, patch) 2008-01-22 09:23 UTC, Suman Manjunath	reviewed	Details \| Review
proposed evo patch (1.67 KB, patch) 2009-04-06 18:20 UTC, Milan Crha	committed	Details \| Review

Description Akhil Laddha 2007-10-30 14:56:46 UTC

Just started evolution and eds crashed.



libecal-ERROR **: file e-cal-util.c: line 316 (compute_alarm_range): assertion failed: (*alarm_start <= *alarm_end)
aborting...

Program received signal SIGABRT, Aborted.

+ Trace 173940

Thread NaN (LWP 7654)

#0 ??
#1 ??
#2 ??
#3 ??
#4 raise
from /lib/libc.so.6
#5 abort
from /lib/libc.so.6
#6 IA__g_logv
#7 IA__g_log
#8 IA__g_assert_warning
at gmessages.c line 552
#9 compute_alarm_range
at e-cal-util.c line 316
#10 e_cal_util_generate_alarms_for_comp
at e-cal-util.c line 585
#11 func_has_alarms_in_range
at e-cal-backend-sexp.c line 859
#12 e_sexp_term_eval
at e-sexp.c line 710
#13 e_sexp_eval
at e-sexp.c line 1306
#14 e_cal_backend_sexp_match_comp
at e-cal-backend-sexp.c line 1272
#15 e_cal_backend_groupwise_get_object_list
#16 e_cal_backend_groupwise_start_query
at e-cal-backend-groupwise.c line 1590
#17 e_cal_backend_start_query
at e-cal-backend.c line 693
#18 impl_EDataCalView_start
at e-data-cal-view.c line 254
#19 _ORBIT_skel_small_GNOME_Evolution_Calendar_CalView_start
at Evolution-DataServer-Calendar-common.c line 16
#20 ORBit_POAObject_invoke
at poa.c line 1142
#21 ORBit_OAObject_invoke
at orbit-adaptor.c line 338
#22 ORBit_small_invoke_adaptor
at orbit-small.c line 844
#23 ORBit_POAObject_handle_request
at poa.c line 1351
#24 ORBit_POAObject_invoke_incoming_request
at poa.c line 1421
#25 giop_thread_queue_process
at giop.c line 771
#26 giop_mainloop_handle_input
at giop.c line 461
#27 link_source_dispatch
at linc-source.c line 159
#28 g_main_dispatch
at gmain.c line 2061
#29 IA__g_main_context_dispatch
at gmain.c line 2613
#30 g_main_context_iterate
at gmain.c line 2694
#31 IA__g_main_loop_run
at gmain.c line 2898
#32 bonobo_main
at bonobo-main.c line 311
#33 main
at server.c line 418

Comment 1 Suman Manjunath 2008-01-22 09:23:51 UTC

Created attachment 103409 [details] [review]
patch in e-cal-util.c

The whole logic seems right.. There was only one issue though - icaldurationtype_as_int would return an 'int' but was being assigned to a 'time_t' [some machines define time_t as an unsigned int].. that's one case where 'alarm_start' could become greater than 'alarm_end' 

I'm not sure if the patch fixes the bug, but it definitely is a part of the fix.

Comment 2 Srinivasa Ragavan 2008-01-24 04:04:47 UTC

I don't think it is much relavent.

Comment 3 Matthew Barnes 2008-03-11 01:01:38 UTC

Bumping version to a stable release.

Comment 4 Milan Crha 2008-07-03 17:45:53 UTC

All the query is somehow funny, see the expression statement:
(has-alarms-in-range? (make-time \"20071101T135153Z\")
                      (make-time \"20071030T183000Z\"))

These two are in the different order too, thus
start=1193925113 is greater than
  end=1193769000

and because these values are assigned initially to *alarm_start and *alarm_end,
then the assertion is supposed to be triggered since the beginning.

The question is: "How can one request such query?"

Comment 5 Milan Crha 2009-04-06 16:25:01 UTC

*** Bug 548396 has been marked as a duplicate of this bug. ***

Comment 6 Milan Crha 2009-04-06 17:59:28 UTC

I was able to trigger this only ever when going back in system time, as these values seem to be got from gconf, time between last notified and actual time.
Is it possible you played with either gconf or the system time here? Nonetheless, the check for correct value stored in gconf might not hurt.

Comment 7 Milan Crha 2009-04-06 18:20:07 UTC

Created attachment 132210 [details] [review]
proposed evo patch

for evolution;

Sanitize values from GConf before using them.

Comment 8 Srinivasa Ragavan 2009-04-27 05:11:01 UTC

Seems fine for me. To master & stable.

Comment 9 Milan Crha 2009-04-27 10:19:14 UTC

Created commit d4def43 in master.
Created commit 796768f in gnome-2-26.