This doesn't work on amd64. If you run it, create a new appointment and then hit save it segfaults there and then. Let me know if there are any tests I can run. The backtrace is: #0 0x000000000042b3e4 in icalcomponent_isa_component (component=0x600000000) at icalcomponent.c:386 #1 0x000000000042ab47 in icalcomponent_add_children (impl=0x9dbb30, args=0x7ffffff87650) at icalcomponent.c:101 #2 0x000000000042ae09 in icalcomponent_vanew (kind=ICAL_VEVENT_COMPONENT) at icalcomponent.c:163 #3 0x00000000004139a0 in appt_add_internal (appt=0x9d8c00, add=1, uid=0x0, cre_time= {year = 0, month = 0, day = 0, hour = 0, minute = 0, second = 0, is_utc = 0, is_date = 0, is_daylight = 0, zone = 0x0}) at ical-code.c:1023 #4 0x000000000041451f in xfical_appt_add (appt=0x9d8c00) at ical-code.c:1152 #5 0x000000000040a6fc in save_xfical_from_appt_win (apptw=0x941b20) at appointment.c:535 #6 0x000000000040a896 in on_appSave_clicked_cb (button=0x5cf800, user_data=0x941b20) at appointment.c:577 #7 0x00002adb1f7a2910 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #8 0x00002adb1f7b1af2 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #9 0x00002adb1f7b2fcc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #10 0x00002adb1f7b682d in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #11 0x00002adb1f7a2910 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0x00002adb1f7b1af2 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #13 0x00002adb1f7b2fcc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0x00002adb1f7b3383 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0x00002adb1dbaccb7 in _gtk_button_set_depressed () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x00002adb1f7a2910 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #17 0x00002adb1f7b1630 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #18 0x00002adb1f7b2fcc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #19 0x00002adb1f7b3383 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #20 0x00002adb1dbac269 in _gtk_button_paint () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x00002adb1dc655e0 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #22 0x00002adb1f7a2910 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #23 0x00002adb1f7b1c9d in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #24 0x00002adb1f7b2d0c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #25 0x00002adb1f7b3383 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #26 0x00002adb1dd441c5 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #27 0x00002adb1dc639eb in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #28 0x00002adb1dc63e67 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #29 0x00002adb1dfb02ac in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #30 0x00002adb1fd25afd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #31 0x00002adb1fd28dc5 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #32 0x00002adb1fd2908a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #33 0x00002adb1dc63252 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #34 0x0000000000419cfb in main (argc=1, argv=0x7ffffff8ba78) at main.c:496 I had a poke around in the source but didn't see anything obvious though there are some slightly suspicious looking pointer casts in icalrecur.c that give warnings. icalrecur.c:1721: warning: cast to pointer from integer of different size icalrecur.c:1733: warning: cast to pointer from integer of different size icalrecur.c:1746: warning: cast to pointer from integer of different size icalfileset.c:183: warning: cast from pointer to integer of different size icalfileset.c:212: warning: cast to pointer from integer of different size
the call to appt_add_internal looks suspecious. Checking more later.
No, orage code it quite ok. The problem is indeed in the libical code. But as I do not have 64 bit machine and the code looks valid, this may be difficult to fix. It clearly is some 64 bit compatibility thing. All those warnings and the segfault seem to come from void pointer handling. could you try to change int icalcomponent_isa_component (void* component) to int icalcomponent_isa_component (icalcomponent* component) both in icalcomponent.c and icalcomponent.h Although I believe this will just move the problem somewhere else.
Sorry, sadly this doesn't change anything and I still get the same backtrace.
as I do not have 64 bit system available I am not able to test this, which means it will not be easy to fix it either since I have no idea why some of those pointers misbehave. Perhaps there is a compiler switch which forces to use 32 (or 64) bit pointers always. Sorry, but looks like this will be open for long time.
If you can give me some pointers for areas in the code that you suspect might be dodgy or good ways to track this down I can try and do so when I get some free time. I did try orage in electric fence but it got stuck in some problems in underlying libraries before it got as far orage and I wasn't sure if electric fence works on amd64 :(
I think I've nailed it :) in ical-code.c in appt_add_internal() the call ievent = icalcomponent_vanew(ICAL_VEVENT_COMPONENT , icalproperty_new_uid(xf_uid) , icalproperty_new_categories("ORAGENOTE") , icalproperty_new_class(ICAL_CLASS_PUBLIC) , icalproperty_new_dtstamp(dtstamp) , icalproperty_new_created(create_time) , 0); is the culprit. That last zero should either be cast to (void*) or simply changed to NULL.
Created attachment 685 Fix segfault when saving event
Thanks a lot ! fixed in svn revision 22586. Fix will appear in RC1. Same code is used in other places also.
You might also want the next attachment which fixes another case of icalcomponent_vanew to use NULL not 0.
Created attachment 706 Another couple of icalcomponent_vanew fixes
Created attachment 707 more icalcomponent_vanew fixes Oops, I missed these ones.
fixed in svn revision 22745. But looking to the ical code, it seems thay have used 0 in the meaning of NULL in many more places. Let's hope those do not cause problems or there may be a lot more work to do.
*** Bug 2169 has been marked as a duplicate of this bug. ***
Moving all bugs to new Orage product.