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 597567 - Crash in comp_subject()
Crash in comp_subject()
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.28.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 613005 646709 651033 651237 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-06 15:52 UTC by Pedro Villavicencio
Modified: 2011-06-21 11:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
iCal invitation mail causing the crash in Evolution (4.31 KB, text/plain)
2009-12-01 10:45 UTC, Steven Bakker
  Details
Message that crashed evolution (3.03 KB, text/plain)
2009-12-01 12:19 UTC, Nikolay Bryskin
  Details
another message that crashed evolution (1.17 KB, text/calendar)
2009-12-02 10:10 UTC, Christian
  Details
eds patch (1.81 KB, patch)
2010-10-21 09:08 UTC, Milan Crha
committed Details | Review
evo patch (1.64 KB, patch)
2010-10-21 09:09 UTC, Milan Crha
committed Details | Review

Description Pedro Villavicencio 2009-10-06 15:52:25 UTC
this report has been filed here:

https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/442627

"I received an email message with an attached ical event in an IMAP folder.
After I had pressed the accept button in this email Evolution crashed."

".

Thread 1 (process 17868)

  • #0 comp_subject
    at itip-utils.c line 668
  • #1 itip_send_comp
    at itip-utils.c line 1246
  • #2 view_response_cb
    at itip-formatter.c line 1977
  • #3 IA__g_cclosure_marshal_VOID__INT
    at /build/buildd/glib2.0-2.20.1/gobject/gmarshal.c line 216
  • #4 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #5 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3247
  • #6 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2980
  • #7 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #8 button_clicked_cb
    at itip-view.c line 779
  • #9 IA__g_cclosure_marshal_VOID__VOID
    at /build/buildd/glib2.0-2.20.1/gobject/gmarshal.c line 77
  • #10 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #11 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3247
  • #12 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2980
  • #13 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #14 IA__gtk_button_clicked
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkbutton.c line 1106
  • #15 gtk_real_button_released
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkbutton.c line 1702
  • #16 IA__g_cclosure_marshal_VOID__VOID
    at /build/buildd/glib2.0-2.20.1/gobject/gmarshal.c line 77
  • #17 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 878
  • #18 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #19 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3177
  • #20 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2980
  • #21 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #22 IA__gtk_button_released
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkbutton.c line 1098
  • #23 gtk_button_button_release
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkbutton.c line 1594
  • #24 _gtk_marshal_BOOLEAN__BOXED
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmarshalers.c line 84
  • #25 g_type_class_meta_marshal
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 878
  • #26 IA__g_closure_invoke
    at /build/buildd/glib2.0-2.20.1/gobject/gclosure.c line 767
  • #27 signal_emit_unlocked_R
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3285
  • #28 IA__g_signal_emit_valist
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 2990
  • #29 IA__g_signal_emit
    at /build/buildd/glib2.0-2.20.1/gobject/gsignal.c line 3037
  • #30 gtk_widget_event_internal
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkwidget.c line 4761
  • #31 IA__gtk_propagate_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 2396
  • #32 IA__gtk_main_do_event
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 1601
  • #33 gdk_event_dispatch
    at /build/buildd/gtk+2.0-2.16.1/gdk/x11/gdkevents-x11.c line 2364
  • #34 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 1814
  • #35 g_main_context_iterate
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2448
  • #36 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2656
  • #37 bonobo_main
    at bonobo-main.c line 311
  • #38 main
    at main.c line 704

Comment 1 Milan Crha 2009-11-30 16:13:02 UTC
Downstream bug report about the same in 2.28.0:
https://bugzilla.redhat.com/show_bug.cgi?id=542576

Is it possible to attach here that invitation calendar item, please? (Do not forget to strip any private information from there, like names, email addresses, server addresses and such, just keep the information format, like from "user@domain.com" do "xxxx@yyyyyy.com" (see the letters count matches)).

I see where the issue is, but I would like to know whether it's a correct information incorrectly parsed within Evolution, or incorrect information stored in the invitation, which is not skipped in Evolution code.
Comment 2 Steven Bakker 2009-12-01 10:45:32 UTC
Created attachment 148814 [details]
iCal invitation mail causing the crash in Evolution

Thanks for looking into this. I've attached the (anonymised) invitation. FYI, I've seen these crashes with other invitations as well (and previous versions of Evolution), but so far, I've only ever gotten iCal invitations from people with Apple Mail, so I cannot say for sure whether it's only a problem with Apple Mail invitations.
Comment 3 Nikolay Bryskin 2009-12-01 12:19:22 UTC
Created attachment 148820 [details]
Message that crashed evolution

This is my message that crashed evolution when I tried to accept it.
Comment 4 Milan Crha 2009-12-01 13:44:33 UTC
Thanks for the data. The both seem to be correct, there is only one possible issue with the first message and the first attendee there:
> ATTENDEE;CN="Xxxxx Xxxxxxxxx xx Xxxxx";CUTYPE=INDIVIDUAL;EMAIL="xxxxxxxx
>  @yyyyyyyyy";PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:
>  xxxxxxxx@yyyyyyyyy
as the second line is folded just after "mailto:".

The second mail doesn't have anything like this, and it still fails to parse the attendee email from there, also for the first attendee.

I'll investigate further, I'm only confirming this bug.
Comment 5 Christian 2009-12-02 10:10:27 UTC
Created attachment 148887 [details]
another message that crashed evolution

If it helps, this is one of the messages that caused a crash in Evolution for me. It comes from someone who uses Apple Mail. What's irritating is that there seems to be real spaces in the email-addresses of the attendees (i opened the file in gedit and in gvim, both show the space in "xx@ yy.de". Could this cause some error?
Comment 6 Milan Crha 2009-12-02 11:22:02 UTC
Thanks for all the data. I looked in all three samples and it turned out that libical, a library Evolution is using to parse those invitations, is behaving strangely for parameters of attendees which it doesn't know. It's an EMAIL and SVP parameters in our case. All works as expected when I remove these from the ATTENDEE lines.
Comment 7 Milan Crha 2009-12-02 12:25:59 UTC
There is some effort in the upstream libical to be able to track unknown parameters [1], but it's quite new, same as RFC 5545. We might wait for the next stable release of libical with the patch from [1] applied, or configure libical same as mozilla does, with undefined ICAL_ERRORS_ARE_FATAL. but as long as evolution is using the upstream version, thus that installed in a system, the configure is question of distro maintainers, not anything in evolution.

Just to not forget, when the right version of libical will be widely available, we should add to each main(...) call like this:
>  ical_set_unknown_token_handling_setting (ICAL_ASSUME_IANA_TOKEN);
either in the main(...) or anywhere else, unless they'll change default value to this.

[1] http://sourceforge.net/mailarchive/forum.php?thread_name=4B06B149.2080405%40scalix.com&forum_name=freeassociation-devel
Comment 8 Milan Crha 2009-12-08 19:54:15 UTC
Chen, any idea what we should do with this? It's obvious that Evolution shouldn't crash, but simply ignoring the error is not an option either, as there is an information (attendee) lost. This is not that easy because eds is depending on an upstream/system libical these days, thus we are forced to wait for a proper fix until it's included there.
Comment 9 Akhil Laddha 2010-03-16 07:17:20 UTC
*** Bug 613005 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Nelson 2010-10-20 18:16:47 UTC
In my opinion, lost data is preferable to a crash, although of course, neither is ideal. If it is possible to detect the particular error that is currently causing the crash, can it just be ignored and a warning presented to the user that data is probably being lost? I know that I for one, would welcome that change, as I am pretty much prevented from using Evolution because of this bug (I receive 6 or more .ics files from iCal every day, each of which crashes Evolution when I accept them).
Comment 11 Milan Crha 2010-10-21 08:09:49 UTC
Thanks for a reminder on this. There is not much we can do, unless creating our own iCal parser "just to prepare it for libical", which is not much practical.

I looked on the libical upstream release and I see that they did a release with the fix included just recently (they are not releasing too often), so I'll create a patch which will check whether is evolution or evolution-data-server compiled against this version and it'll do the thing from comment #7.
Comment 12 Milan Crha 2010-10-21 09:08:11 UTC
Created attachment 172904 [details] [review]
eds patch

for evolution-data-server;

Check and use ical_set_unknown_token_handling_setting in e-calendar-factory, if available (libical 0.46+).
Comment 13 Milan Crha 2010-10-21 09:09:03 UTC
Created attachment 172905 [details] [review]
evo patch

for evolution;

Check and use ical_set_unknown_token_handling_setting in evolution itself, if available (libical 0.46+)
Comment 14 Milan Crha 2010-10-21 09:45:07 UTC
Created commit 1e3daec in eds master (2.91.2+)
Created commit d4adff1 in evo master (2.91.2+)

Created commit 5ef7c6d in eds gnome-2-32 (2.32.1+)
Created commit ac0f082 in evo gnome-2-32 (2.32.1+)

Fix works only when compiled with libical 0.46 or later, thus this is partially NotGnome bug.
Comment 15 Fabio Durán Verdugo 2011-04-04 14:21:04 UTC
*** Bug 646709 has been marked as a duplicate of this bug. ***
Comment 16 Fabio Durán Verdugo 2011-05-27 14:49:51 UTC
*** Bug 651237 has been marked as a duplicate of this bug. ***
Comment 17 Milan Crha 2011-06-21 11:41:37 UTC
*** Bug 651033 has been marked as a duplicate of this bug. ***