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 653154 - Crash when constructing calendar view
Crash when constructing calendar view
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
3.2.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 653658 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-06-22 09:18 UTC by Dan Vrátil
Modified: 2013-09-13 01:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace (9.98 KB, text/plain)
2011-06-22 09:18 UTC, Dan Vrátil
  Details
evo patch (8.36 KB, patch)
2011-06-27 09:29 UTC, Milan Crha
committed Details | Review

Description Dan Vrátil 2011-06-22 09:18:24 UTC
Created attachment 190417 [details]
Backtrace

Evo crashes anytime I try to switch to calendar or start Evo with -c calendar. 

I tried to run it in Valgrind, but it didn't crash, so I suppose it depends on some specific sequence of events.

The crash is preceded by following glib warning:

(evolution:25304): GLib-GObject-CRITICAL **: g_object_set_data: assertion `G_IS_OBJECT (object)' failed

(evolution:25304): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(evolution:25304): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed


Reproducible on latest git.
Comment 1 André Klapper 2011-06-22 09:20:18 UTC
crash => critical!
Comment 2 Milan Crha 2011-06-22 09:21:48 UTC
Top of the backtrace:

  • #0 g_type_check_instance_cast
    at gtype.c line 3980
  • #1 e_week_view_reshape_event_span
    at e-week-view.c line 3259
  • #2 e_week_view_reshape_events
    at e-week-view.c line 2869
  • #3 e_week_view_check_layout
    at e-week-view.c line 2811
  • #4 e_week_view_size_allocate
    at e-week-view.c line 1215
  • #5 g_closure_invoke
    at gclosure.c line 767
  • #6 signal_emit_unlocked_R
    at gsignal.c line 3182
  • #7 g_signal_emit_valist
    at gsignal.c line 2983
  • #8 g_signal_emit
    at gsignal.c line 3040
  • #9 gtk_widget_size_allocate
    at gtkwidget.c line 4870
  • #10 gtk_notebook_size_allocate
    at gtknotebook.c line 2404

Comment 3 Milan Crha 2011-06-23 17:02:21 UTC
After investigation with Dan we realized that this all does e_client_check_capability() call at e_week_view_reshape_event_span(), the one few lines below an assignment to span->text_item. This is because the e_client_check_capability() makes a DBus call to get capabilities, and it also iterates the main context, thus, till they are received, the week-view regenerates span array and then is everything "simply broken" with the local variable 'span'.

I cannot think of anything better than reading capabilities just after open, to have them cached and not fetch them on demand. When I tried with pushing thread default main context then it didn't work, maybe I did something incorrectly.

Also, the crash itself is caused by 
> g_object_get (G_OBJECT (span->text_item), "text", &text, NULL);
few lines below in this function, because this fails and keeps 'text' variable uninitialized. Thus do not forget to initialize it to NULL too.
Comment 4 Milan Crha 2011-06-27 09:29:25 UTC
Created attachment 190739 [details] [review]
evo patch

for evolution;

This retrieves capabilities just after successful open of an EClient. It requires some changes in evolution-data-server too.
Comment 5 Milan Crha 2011-06-27 09:32:22 UTC
Created commit af86bdd in eds master (3.1.3+)
Created commit 46eec90 in evo master (3.1.3+)
Comment 6 Fabio Durán Verdugo 2011-06-29 20:36:06 UTC
*** Bug 653658 has been marked as a duplicate of this bug. ***