GNOME Bugzilla – Bug 335622
Click Description field causes Evolution to crash.
Last modified: 2007-06-15 21:19:49 UTC
1) Launch -> Evolution 2) Goto "Calendars" -> Right click on the empty field 3) Choose "New Appointment" 4) When a dialog pop-up -> Click on "Time" column 5) Insert "s" into it. -> A notification dialog pop-up 6) Click "OK" -> Click on "Description" box 7) Evolution crash.
This is where this stack trace belongs ;-) Hope it's useful.
+ Trace 67159
Thread 1 (Thread -1209100096 (LWP 4588))
this is my trace, a little different:)
+ Trace 67200
unique stack trace changing product to gtk+ Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. please install gtk+ debugging libraries
First we input a wrong format time in time column, and then clicked on the textview, the gtk_text_view_start_selection_drag was invoked, and an evolution notification dialog pop-up, so textview had no chance to invoke gtk_text_view_end_selection_drag. So when we click textview again, the gtk_text_view_start_selection_drag will crash because g_assert (text_view->selection_drag_handler == 0); failed. Here is the trace.
+ Trace 67266
Thanks for this analysis. We should probably end the drag when we get a grab notify.
It actually reveals this bug as a dupe of another bug which is even cited in the textview sources. *** This bug has been marked as a duplicate of 74620 ***
I have reopened the bug because I do not believe it it a dup of 74620. The button press event causes the dialog to be displayed with the stack trace below and the button release event is sent to the GtkMessageDialog so gtk_text_view_button_release_event is not called. fe367c37 pollsys (81a5650, 7, 8045398, 0) fe31c792 poll (81a5650, 7, 5cc4) + 52 fe3f1637 g_main_context_iterate (809dd58, 1, 1, 80807d0) + 397 fe3f1c70 g_main_loop_run (8528460) + 1b8 fe6b3df1 gtk_dialog_run (8592b28, 8045580, 8571f28, fe90ffd4, fe35f7b1, 804549c) + 135 fef4946c on_date_entry_focus_out (8390210, 8406f70, 8571190) + 70 fe723555 _gtk_marshal_BOOLEAN__BOXED (8571f28, 8045580, 2, 804563c, 804559c, 0) + 71 fe92a41b g_closure_invoke (8571f28, 8045580, 2, 804563c, 804559c) + 107 fe93e3e7 signal_emit_unlocked_R (81bbf48, 0, 8390210, 80457bc, 804563c) + ab7 fe93d126 g_signal_emit_valist (8390210, 49, 0, 80458b0) + 662 fe93d51d g_signal_emit (8390210, 49, 0, 8406f70, 80458d4) + 25 fe82870a gtk_widget_event_internal (8390210, 8406f70) + 212 fe828399 gtk_widget_event (8390210, 8406f70) + 99 fe83421d do_focus_change (8390210, 0) + 75 fe8345c2 gtk_window_real_set_focus (81fa398, 85158f8, 80f8758) + 106 fe93f107 g_cclosure_marshal_VOID__OBJECT (81c7520, 0, 2, 8045afc, 8045a5c, fe8344bc) + 5b fe92a6fc g_type_class_meta_marshal (81c7520, 0, 2, 8045afc, 8045a5c, 1a0) + 40 fe92a41b g_closure_invoke (81c7520, 0, 2, 8045afc, 8045a5c) + 107 fe93e23a signal_emit_unlocked_R (80a26a8, 0, 81fa398, 0, 8045afc) + 90a fe93d388 g_signal_emit_valist (81fa398, 82, 0, 8045d68) + 8c4 fe93d51d g_signal_emit (81fa398, 82, 0, 85158f8) + 25 fe82fbd4 _gtk_window_internal_set_focus (81fa398, 85158f8) + 50 fe82907b gtk_widget_real_grab_focus (85158f8, 80f6860) + b7 fe93e7f1 g_cclosure_marshal_VOID__VOID (81b8978, 0, 1, 8045f3c, 8045e9c, fe828fc4) + 55 fe92a6fc g_type_class_meta_marshal (81b8978, 0, 1, 8045f3c, 8045e9c, a4) + 40 fe92a41b g_closure_invoke (81b8978, 0, 1, 8045f3c, 8045e9c) + 107 fe93e23a signal_emit_unlocked_R (81a3670, 0, 85158f8, 0, 8045f3c) + 90a fe93d388 g_signal_emit_valist (85158f8, 37, 0, 80461a8) + 8c4 fe93d51d g_signal_emit (85158f8, 37, 0) + 25 fe828f2b gtk_widget_grab_focus (85158f8) + 53 fe7d05c8 gtk_text_view_button_press_event (85158f8, 85a76a0, 80f6860) + 24
removing ancient gnome target milestone.
Created attachment 74414 [details] simple test app that reproduce the problem
Created attachment 74415 [details] [review] proposed patch
Find attached a simple test app which reproduce the problem experienced in evolution. To reproduce : - click on the textview - click Ok in the dialog box - click again in the textview then : Gtk-ERROR **: file gtktextview.c: line 5665: assertion failed: (text_view->selection_drag_handler == 0) aborting... Abort (core dumped) The problem is that GtkEntry has a callback bound to focus_out_event which if a condition isn't met popups up a dialog and then sets the focus back to the GtkEntry. The problem is that the focus_out event here is generated by a call to gtk_widget_grab_focus in gtk_text_view_button_press_event. So at that stage the textview is in "selection" mode hence text_view->selection_drag_handler != 0 but doesn't have the focus anymore. So the next time the user press on the textview gtk_text_view_button_press_event tries to initiate a drag again and reaches the g_assert in gtk_text_view_start_selection_drag. Two possible solutions would be to : - end the selection when the textview is focused out by the entry focus grab. But strangly enough gtk_text_view_focus_out_event isn't called when the entry grabs the focus. - end the selection if the textview doesn't the focus anymore in selection_motion_event_handler. Find attached a patch which implements the second (bandaid) solution.
So, it turns out that calling grab_focus from a focus-out event handler is a seriously bad idea. What I am doing for now is to replace the assert in gtk_text_view_start_selection_drag by an early return. There are several bugs open about crashes because people manage to trigger that assertion.
2006-12-20 Matthias Clasen <mclasen@redhat.com> * gtk/gtktextview.c (gtk_text_view_start_selection_drag): Silently return if a drag is already in progress, rather than asserting. (#335622, Li Yuan, testcase by Erwann Chenede)
i wonder if bug 329356, bug 376779, bug 355701, bug 371288, bug 362892, bug 351671 and bug 344826 are duplicates of this one here?
*** Bug 329356 has been marked as a duplicate of this bug. ***