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 86215 - Pan crashes when editing filters
Pan crashes when editing filters
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.12.0
Other Linux
: Normal normal
: 0.12.2
Assigned To: Charles Kerr
Charles Kerr
Depends on:
Blocks:
 
 
Reported: 2002-06-22 23:53 UTC by Carl Hudkins
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Runlog & backtrace of segfault while editing filters (10.03 KB, application/x-bzip2)
2002-06-23 00:24 UTC, Carl Hudkins
Details

Description Carl Hudkins 2002-06-22 23:53:53 UTC
Go to Rules; pick a rule and edit it.
Go to Filters tab; edit filters.
(To ensure a crash, work on several different filters, or set up many 
conditions in one filter.)
Ok the conditions; press Ok on the Filters dialog.
Pan segfaults at this point.
Comment 1 Carl Hudkins 2002-06-23 00:24:57 UTC
Created attachment 9405 [details]
Runlog & backtrace of segfault while editing filters
Comment 2 Christophe Lambin 2002-06-24 19:16:51 UTC
Confirmed.  Error messages just before the segfault are:


(pan:1856): GLib-GObject-WARNING **: invalid uninstantiatable type
`<invalid>' in cast to `GtkOptionMenu'

(pan:1856): Gtk-CRITICAL **: file gtkoptionmenu.c: line 262
(gtk_option_menu_set_menu): assertion `GTK_IS_OPTION_MENU
(option_menu)' failed

(pan:1856): GLib-GObject-WARNING **: invalid uninstantiatable type
`<invalid>' in cast to `GtkOptionMenu'

(pan:1856): Gtk-CRITICAL **: file gtkoptionmenu.c: line 312
(gtk_option_menu_set_history): assertion `GTK_IS_OPTION_MENU
(option_menu)' failed

(pan:1856): GLib-GObject-WARNING **: invalid uninstantiatable type
`<invalid>' in cast to `GtkWidget'

(pan:1856): Gtk-CRITICAL **: file gtkwidget.c: line 1770
(gtk_widget_show_all): assertion `GTK_IS_WIDGET (widget)' failed
Comment 3 Charles Kerr 2002-07-15 20:08:20 UTC
The germane parts of the .bz2 file:

Program received signal SIGSEGV, Segmentation fault.^M
[Switching to Thread 1024 (LWP 21426)]^M
0x403fe2fc in g_type_check_instance_cast () from
/usr/lib/libgobject-2.0.so.0^M
(gdb) bt^M
  • #0 g_type_check_instance_cast
    from /usr/lib/libgobject-2.0.so.0^M
  • #1 populate_filter_text
    at rule-edit-ui.c line 331
  • #2 populate_filter_tab
    at rule-edit-ui.c line 384
  • #3 pan_callback_call
    at pan-callback.c line 69
  • #4 filter_manager_set_filters
    at filter-manager.c line 226
  • #5 filter_dialog_response_cb
    at filter-ui.c line 159
  • #6 g_cclosure_marshal_VOID
    from /usr/lib/libgobject-2.0.so.0^M
  • #7 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0^M
  • #8 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0^M
  • #9 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0^M
  • #10 gtk_signal_emit
    from /usr/lib/libgtk-x11-2.0.so.0^M
  • #11 gtk_dialog_response
    from /usr/lib/libgtk-x11-2.0.so.0^M
  • #12 gtk_dialog_get_has_separator
    from /usr/lib/libgtk-x11-2.0.so.0^M
  • #13 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0^M
  • #14 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0^M
  • #15 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0^M
  • #16 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0^M
  • #17 gtk_signal_emit
    from /usr/lib/libgtk-x11-2.0.so.0^M
  • #18 gtk_button_clicked
    from /usr/lib/libgtk-x11-2.0.so.0^M

Comment 4 Christophe Lambin 2002-07-17 23:03:55 UTC
Brain dump before going to bed:

The root cause appears to be that rule-edit-ui.c::dialog_close_cb()
isn't called when we gtk_widget_destroy() it in
rule-ui.c::edit_dialog_response_cb(), despite the fact that we've
connected the "close" signal to it.

Since the 'filters-changed' callback gets removed in
dialog_close_cb(), we eventually end up calling filters_changed_cb()
for an invalid (destroyed) dialog.

No idea why the "close" signal isn't triggered when we destroy the
widget yet.