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 467698 - crash because realizing a widget with NULL colormap
crash because realizing a widget with NULL colormap
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.12.x
Other All
: High critical
: ---
Assigned To: gtk-bugs
gtk-bugs
: 469735 473068 476534 477257 492211 501279 501771 511883 513332 515396 517189 517327 517518 520716 520925 526077 528303 528316 529752 531144 531567 531618 532894 533001 533078 534183 539572 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-17 15:52 UTC by jvdmail
Modified: 2008-06-22 10:41 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
fix (426 bytes, patch)
2008-01-15 18:49 UTC, Sébastien Granjoux
committed Details | Review
test case for this bug (3.83 KB, text/plain)
2008-02-12 20:21 UTC, Sébastien Granjoux
  Details

Description jvdmail 2007-08-17 15:52:49 UTC
What were you doing when the application crashed?
closing the messages pane


Distribution: Unknown
Gnome Release: 2.18.3 2007-07-07 (Archlinux)
BugBuddy Version: 2.18.1

System: Linux 2.6.22-ARCH #1 SMP PREEMPT Wed Aug 15 23:33:00 CEST 2007 i686
X Vendor: The X.Org Foundation
X Vendor Release: 10300000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: gnome

Memory status: size: 72933376 vsize: 72933376 resident: 32215040 share: 18210816 rss: 32215040 rss_rlim: 4294967295
CPU usage: start_time: 1187364034 rtime: 702 utime: 662 stime: 40 cutime:342 cstime: 21 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/anjuta'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1226709312 (LWP 10000)]
0xb7f05410 in __kernel_vsyscall ()

Thread 1 (Thread -1226709312 (LWP 10000))

  • #0 __kernel_vsyscall
  • #1 ??
    from /lib/libpthread.so.0
  • #2 libgnomeui_segv_handle
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 gtk_style_realize
    from /usr/lib/libgtk-x11-2.0.so.0
  • #5 gtk_style_attach
    from /usr/lib/libgtk-x11-2.0.so.0
  • #6 gtk_widget_real_realize
    from /usr/lib/libgtk-x11-2.0.so.0
  • #7 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #8 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #9 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #10 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #11 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #13 gtk_widget_realize
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 gtk_widget_set_child_visible
    from /usr/lib/libgtk-x11-2.0.so.0
  • #16 gtk_notebook_calculate_tabs_allocation
    from /usr/lib/libgtk-x11-2.0.so.0
  • #17 gtk_notebook_pages_allocate
    from /usr/lib/libgtk-x11-2.0.so.0
  • #18 gtk_notebook_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #19 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #20 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #21 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #22 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #23 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #24 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #25 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #26 gdl_dock_item_map
    from /usr/lib/libgdl-1.so.0
  • #27 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #28 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #29 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #30 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #31 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #32 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #33 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #34 gtk_notebook_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #35 gdl_switcher_map
    from /usr/lib/libgdl-1.so.0
  • #36 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #37 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #38 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #39 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #40 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #41 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #42 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #43 gdl_dock_item_map
    from /usr/lib/libgdl-1.so.0
  • #44 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #45 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #46 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #47 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #48 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #49 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #50 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #51 gtk_widget_set_parent
    from /usr/lib/libgtk-x11-2.0.so.0
  • #52 gdl_dock_paned_dock
    from /usr/lib/libgdl-1.so.0
  • #53 gdl_marshal_VOID__OBJECT_ENUM_BOXED
    from /usr/lib/libgdl-1.so.0
  • #54 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #55 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #56 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #57 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #58 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #59 gdl_dock_object_dock
    from /usr/lib/libgdl-1.so.0
  • #60 gdl_dock_paned_add
    from /usr/lib/libgdl-1.so.0
  • #61 g_cclosure_marshal_VOID__OBJECT
    from /usr/lib/libgobject-2.0.so.0
  • #62 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #63 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #64 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #65 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #66 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #67 gtk_container_add
    from /usr/lib/libgtk-x11-2.0.so.0
  • #68 gdl_dock_object_real_reduce
    from /usr/lib/libgdl-1.so.0
  • #69 gdl_dock_object_reduce
    from /usr/lib/libgdl-1.so.0
  • #70 gdl_dock_object_real_detach
    from /usr/lib/libgdl-1.so.0
  • #71 g_cclosure_marshal_VOID__BOOLEAN
    from /usr/lib/libgobject-2.0.so.0
  • #72 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #73 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #74 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #75 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #76 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #77 gdl_dock_object_detach
    from /usr/lib/libgdl-1.so.0
  • #78 gdl_dock_item_hide_item
    from /usr/lib/libgdl-1.so.0
  • #79 gdl_dock_item_grip_close_clicked
    from /usr/lib/libgdl-1.so.0
  • #80 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #81 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #82 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #83 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #84 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #85 gtk_button_clicked
    from /usr/lib/libgtk-x11-2.0.so.0
  • #86 gtk_real_button_released
    from /usr/lib/libgtk-x11-2.0.so.0
  • #87 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #88 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #89 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #90 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #91 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #92 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #93 gtk_button_released
    from /usr/lib/libgtk-x11-2.0.so.0
  • #94 gtk_button_button_release
    from /usr/lib/libgtk-x11-2.0.so.0
  • #95 _gtk_marshal_BOOLEAN__BOXED
    from /usr/lib/libgtk-x11-2.0.so.0
  • #96 g_type_class_meta_marshal
    from /usr/lib/libgobject-2.0.so.0
  • #97 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #98 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #99 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #100 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #101 gtk_widget_event_internal
    from /usr/lib/libgtk-x11-2.0.so.0
  • #102 gtk_propagate_event
    from /usr/lib/libgtk-x11-2.0.so.0
  • #103 gtk_main_do_event
    from /usr/lib/libgtk-x11-2.0.so.0
  • #104 gdk_event_dispatch
    from /usr/lib/libgdk-x11-2.0.so.0
  • #105 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #106 g_main_context_iterate
    from /usr/lib/libglib-2.0.so.0
  • #107 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #108 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #109 main
  • #0 __kernel_vsyscall


----------- .xsession-errors (5324 sec old) ---------------------
 file:///home/jay/projects/cncpp/src/tree.hh linenum -1 activate? true addToCurrentBuffer? false
kdevelop: MultiBuffer
kdevelop (core): [void PartController::slotActivePartChanged(KParts::Part*)] 0x8956178
kdevelop (core): ** avoiding to create duplicate history entry **
kdevelop (core): [virtual void SimpleMainWindow::setCaption(const QString&)] 
kdevelop (core):  *** found "set_confdlg" action - unplugging
kdevelop (core):  *** found "file_save" action - disconnecting
kdevelop (core):  *** found "file_reload" action - disconnecting
kdevelop: active part widget is : [KateView pointer (0x8973818) to unnamed widget, geometry=582x688+0+0]
kdevelop:  setting m_activeTabWidget 
kdevelop (abbrev): AbbrevPart::slotActivePartChanged()
kdevelop (abbrev): AbbrevPart::slotActivePartChanged() -- OK
qeditor: CppSupportPart::activePartChanged()
kdevelop: ClassViewPart::activePartChanged(
...Too much output, ignoring rest...
--------------------------------------------------
Comment 1 Johannes Schmid 2007-09-03 10:31:37 UTC
*** Bug 473068 has been marked as a duplicate of this bug. ***
Comment 2 Christian Persch 2007-09-09 19:15:59 UTC
This is most likely due to doing

 gtk_style_attach (widget->style, widget->window)

instead of the correct

 widget->style = gtk_style_attach (widget->style, widget->window)

somewhere in anjuta or a library it uses. Since a gtknotebook is involved, I'd say the problematic widget is either a tab label or tab content widget. (A quick check didn't turn up an error of this kind in anjuta or gdl. Are you using an old version of libvte maybe and embedding a vte widget somewhere?)
Comment 3 Johannes Schmid 2007-09-09 20:15:25 UTC
Thanks for your quick help (p.g.p is incredible...)!

Anjuta can embed a terminal which uses libvte but this crash happens also if this plugin is not loaded so I assume it has no relationship.

Also, I couldn't find any incorrect gtk_style_attach() in anjuta's or gdl's code either and I cannot think of a library we use that could be that buggy because except gdl there are just the usual gnome libs.

However we do some rc_style modifications on the close button of the tab widget (gtk_widget_modify_style()). Could that be the cause of the crash?

Maybe gdl_dock_item_realize (GtkWidget *widget) could cause the crash but I don't know what it does and why.
Comment 4 Christian Persch 2007-09-09 21:24:52 UTC
Epiphany uses the same rc style fiddling for the close button, I don't think that's the problem here.

The vte problem exists in versions < 0.14.2 only btw.

The only way to know for certain would be to get a trace of the crash with full debugging info for gtk, and print the name and widget class name of the widget on the top of the stack, the one that's being realised (#6).

The gdl-dock-item realize function looks ok to me.
Comment 5 Johannes Schmid 2007-09-09 22:02:31 UTC
OK, installed gtk+ with debugging symbols from Ubuntu feisty:

  • #0 gtk_style_realize
    at gtkstyle.c line 839
  • #1 IA__gtk_style_attach
    at gtkstyle.c line 752
  • #2 gtk_widget_real_realize
    at gtkwidget.c line 7000
  • #3 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #4 g_type_class_meta_marshal
    at gclosure.c line 567
  • #5 IA__g_closure_invoke
    at gclosure.c line 490
  • #6 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #7 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #8 IA__g_signal_emit
    at gsignal.c line 2243
  • #9 IA__gtk_widget_realize
    at gtkwidget.c line 2498
  • #10 IA__gtk_widget_map
    at gtkwidget.c line 2415
  • #11 IA__gtk_widget_set_child_visible
    at gtkwidget.c line 5658
  • #12 gtk_notebook_calculate_tabs_allocation
    at gtknotebook.c line 5321
  • #13 gtk_notebook_pages_allocate
    at gtknotebook.c line 5379
  • #14 gtk_notebook_map
    at gtknotebook.c line 1547
  • #15 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #16 g_type_class_meta_marshal
    at gclosure.c line 567
  • #17 IA__g_closure_invoke
    at gclosure.c line 490
  • #18 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #19 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #20 IA__g_signal_emit
    at gsignal.c line 2243
  • #21 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #22 gdl_dock_item_map
    at gdl-dock-item.c line 762
  • #23 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #24 g_type_class_meta_marshal
    at gclosure.c line 567
  • #25 IA__g_closure_invoke
    at gclosure.c line 490
  • #26 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #27 IA__g_signal_emit_valist
  • #28 IA__g_signal_emit
    at gsignal.c line 2243
  • #29 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #30 gtk_notebook_map
    at gtknotebook.c line 1544
  • #31 gdl_switcher_map
    at gdl-switcher.c line 540
  • #32 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #33 g_type_class_meta_marshal
    at gclosure.c line 567
  • #34 IA__g_closure_invoke
    at gclosure.c line 490
  • #35 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #36 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #37 IA__g_signal_emit
    at gsignal.c line 2243
  • #38 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #39 gdl_dock_item_map
    at gdl-dock-item.c line 762
  • #40 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #41 g_type_class_meta_marshal
    at gclosure.c line 567
  • #42 IA__g_closure_invoke
    at gclosure.c line 490
  • #43 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #44 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #45 IA__g_signal_emit
    at gsignal.c line 2243
  • #46 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #47 gtk_container_map_child
    at gtkcontainer.c line 2387
  • #48 gtk_paned_forall
    at gtkpaned.c line 1094
  • #49 IA__gtk_container_forall
    at gtkcontainer.c line 1261
  • #50 gtk_container_map
    at gtkcontainer.c line 2395
  • #51 gtk_paned_map
    at gtkpaned.c line 706
  • #52 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #53 g_type_class_meta_marshal
    at gclosure.c line 567
  • #54 IA__g_closure_invoke
    at gclosure.c line 490
  • #55 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #56 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #57 IA__g_signal_emit
    at gsignal.c line 2243
  • #58 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #59 gdl_dock_item_map
    at gdl-dock-item.c line 762
  • #60 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #61 g_type_class_meta_marshal
    at gclosure.c line 567
  • #62 IA__g_closure_invoke
    at gclosure.c line 490
  • #63 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #64 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #65 IA__g_signal_emit
    at gsignal.c line 2243
  • #66 IA__gtk_widget_map
    at gtkwidget.c line 2417
  • #67 gtk_widget_real_show
    at gtkwidget.c line 2241
  • #68 gdl_dock_object_show
    at gdl-dock-object.c line 329
  • #69 IA__g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 77
  • #70 g_type_class_meta_marshal
    at gclosure.c line 567
  • #71 IA__g_closure_invoke
    at gclosure.c line 490
  • #72 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #73 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #74 IA__g_signal_emit
    at gsignal.c line 2243
  • #75 IA__gtk_widget_show
    at gtkwidget.c line 2224
  • #76 gdl_dock_item_dock
    at gdl-dock-item.c line 1324
  • #77 gdl_dock_notebook_dock
    at gdl-dock-notebook.c line 425
  • #78 gdl_marshal_VOID__OBJECT_ENUM_BOXED
    at libgdlmarshal.c line 161
  • #79 g_type_class_meta_marshal
    at gclosure.c line 567
  • #80 IA__g_closure_invoke
    at gclosure.c line 490
  • #81 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #82 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #83 IA__g_signal_emit
    at gsignal.c line 2243
  • #84 gdl_dock_object_dock
    at gdl-dock-object.c line 579
  • #85 gdl_dock_placeholder_dock
    at gdl-dock-placeholder.c line 413
  • #86 gdl_marshal_VOID__OBJECT_ENUM_BOXED
    at libgdlmarshal.c line 161
  • #87 g_type_class_meta_marshal
    at gclosure.c line 567
  • #88 IA__g_closure_invoke
    at gclosure.c line 490
  • #89 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #90 IA__g_signal_emit_valist
    at gsignal.c line 2199
  • #91 IA__g_signal_emit
    at gsignal.c line 2243
  • #92 gdl_dock_object_dock
    at gdl-dock-object.c line 579
  • #93 gdl_dock_placeholder_add
    at gdl-dock-placeholder.c line 345
  • #94 IA__g_cclosure_marshal_VOID__OBJECT
    at gmarshal.c line 636
  • #95 g_type_class_meta_marshal
    at gclosure.c line 567
  • #96 IA__g_closure_invoke
    at gclosure.c line 490
  • #97 signal_emit_unlocked_R
    at gsignal.c line 2370
  • #98 IA__g_signal_emit_valist
    detail=0, 
    var_args=0xbf8fb170 "��<�H\227L�\230�\217\001lj
Comment 6 Christian Persch 2007-09-10 19:22:25 UTC


  • #0 gtk_style_realize
    at gtkstyle.c line 839

Hmm realising the style of a widget with a null colourmap. So it's probably not the thing I've suspected in comment 2... I've seen a similar crash (gtk_style_realize with null colourmap) in epiphany (bug 353503), but could never find out what is causing it.
Comment 7 Johannes Schmid 2007-09-10 20:51:05 UTC
*** Bug 469735 has been marked as a duplicate of this bug. ***
Comment 8 Johannes Schmid 2007-09-10 20:58:44 UTC
Dear GTK+ developers!

This bug seems to be caused by very strage race conditions but can be reproduced on a 1/10 basis. From the point of an application developer, this seems to be very deep inside gtk+ so maybe you have more ideas about that.

Thanks!
Comment 9 Johannes Schmid 2007-09-15 18:23:46 UTC
*** Bug 477257 has been marked as a duplicate of this bug. ***
Comment 10 Johannes Schmid 2007-09-15 18:23:55 UTC
*** Bug 476534 has been marked as a duplicate of this bug. ***
Comment 11 Johannes Schmid 2007-09-15 18:34:12 UTC
BTW, there are some GTK+ criticals before the crash which might be of interest (seem to have missed to post them before:

(anjuta:14107): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(anjuta:14107): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(anjuta:14107): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed
Comment 12 Johannes Schmid 2007-09-15 18:59:26 UTC
Hmm, some code snippet from gdl which could probably be part of the problem:

    attributes.colormap = gtk_widget_get_colormap (widget);
    attributes.event_mask = (gtk_widget_get_events (widget) |
                             GDK_EXPOSURE_MASK |
                             GDK_BUTTON1_MOTION_MASK |
                             GDK_BUTTON_PRESS_MASK |
                             GDK_BUTTON_RELEASE_MASK);
    attributes_mask = GDK_WA_X | GDK_WA_Y | GDK_WA_VISUAL | GDK_WA_COLORMAP;
    widget->window = gdk_window_new (gtk_widget_get_parent_window (widget), 
                                     &attributes, attributes_mask);
    gdk_window_set_user_data (widget->window, widget);
  
    widget->style = gtk_style_attach (widget->style, widget->window);
    gtk_style_set_background (widget->style, widget->window, 
                              GTK_WIDGET_STATE (item));
    gdk_window_set_back_pixmap (widget->window, NULL, TRUE);

    if (item->child)
        gtk_widget_set_parent_window (item->child, widget->window);
    
    if (item->_priv->grip)
        gtk_widget_set_parent_window (item->_priv->grip, widget->window);

The question is if the GdkColormap might be destroyed in between because gtk_widget_get_colormap will not add a new reference to it. Anyway, assuming we would add a g_object_ref, where to unref it then?
Comment 13 Johannes Schmid 2007-11-02 12:16:11 UTC
*** Bug 492211 has been marked as a duplicate of this bug. ***
Comment 14 Johannes Schmid 2007-11-02 12:17:05 UTC
For me, this seems to be fixed with gtk+ 2.10 and gdl trunk. Can someone confirm this?
Comment 15 Massimo Cora' 2007-11-24 15:19:20 UTC
Hi Johannes,

(In reply to comment #14)
> For me, this seems to be fixed with gtk+ 2.10 and gdl trunk. Can someone
> confirm this?
> 

I think it's not fixed with gtk+ 2.10.

I can always reproduce it. Before now I thought it was a random generated crasher.

steps to reproduce:
1. open Anjuta letting it to have a project loaded automatically from a previous session.
2. On documents panel drag and drop a tab file switching it's position.
3. press F11 [compile].
4. crash.

another way is.
1. as above
2. press F11
3. when messages panel appears and finish building, close the messages panel.
4. crash.

this is the stack:
** Message: MessageViewPlugin: Activating MessageView plugin ...
libanjuta-Message: merged [15] anjuta-message-manager.ui

(anjuta:12687): Gdk-CRITICAL **: gdk_colormap_get_screen: assertion `GDK_IS_COLORMAP (cmap)' failed

(anjuta:12687): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

(anjuta:12687): Gdk-CRITICAL **: gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed

Program received signal SIGSEGV, Segmentation fault.

Thread NaN (LWP 12687)

  • #0 ??
    from /usr//lib/libgtk-x11-2.0.so.0
  • #1 ??

I'm on a Gnome 2.18.3 [dropline gnome slackware], gtk+2-2.10.13 and gdl from trunk.

Hope it helps,
regards,
Massimo

Comment 16 Massimo Cora' 2007-11-26 15:35:57 UTC
Hi Johannes,

I'm getting the same behaviour here with Ubuntu Gutsy and latest Anjuta svn version.
Reproducing steps are the same as comment #15.

IMHO it would be good to investigate the notebook drag and drop features, and in case disable them.

regards,
Massimo

Comment 17 Owen Taylor 2007-11-26 16:27:37 UTC
Re comment #12; no that can't happen; GTK+ is single threaded.

I really suspect that this is a Anjuta/GDL bug, and don't see what the GTK+ developers can contribute to resolving it.

Someone needs to:

 A) Figure out how to reproduce the bug
 B) Reproduce the bug with debugging symbols and --g-fatal-warnings
 C) Track down and fix the *FIRST* critical error, not some later crash

If I had to guess the problem here, it involves an attempt to attach a style to an INPUT_ONLY window, since an INPUT_OUTPUT window *always* has a colormap, even if one isn't explicitly specified in the call to gdk_window_new().
Comment 18 Johannes Schmid 2007-12-03 16:20:11 UTC
*** Bug 501279 has been marked as a duplicate of this bug. ***
Comment 19 Johannes Schmid 2007-12-05 14:35:40 UTC
Hmm, the problem is that it is nearly impossible to debug this though the way to reproduce it in comment #15 works. That's all I can get out of gdb with all debugging packages installed (an gdl build with -O0 -g):

  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/tls/i686/cmov/libc.so.6
  • #2 abort
    from /lib/tls/i686/cmov/libc.so.6
  • #3 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #4 g_log
    from /usr/lib/libglib-2.0.so.0
  • #5 g_return_if_fail_warning
    from /usr/lib/libglib-2.0.so.0
  • #6 IA__gdk_colormap_get_screen
    at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkcolor-x11.c line 1503
  • #7 IA__gtk_style_attach
    at /build/buildd/gtk+2.0-2.12.0/gtk/gtkstyle.c line 747
  • #8 gtk_widget_real_realize
    at /build/buildd/gtk+2.0-2.12.0/gtk/gtkwidget.c line 7972
  • #9 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #10 ??
    from /usr/lib/libgobject-2.0.so.0
  • #11 ??
  • #12 ??

I rather suspect that it crashes once it gets back to the mainloop. The last function calls in gdl/anjuta that I could extract with breakpoints are

gdl_dock_paned_add()
gdl_dock_add_item()
anjuta_app_add_widget_full()

but when I continue, gdb cannot find any more line information until the backtrace above appears.
Comment 20 Sébastien Granjoux 2007-12-24 09:12:14 UTC
I have tried to reproduce the bug on my computer using the procedure given by Massimo but I don't get a crash.

I'm using:
gdl revision 399
anjuta revision 3382
gnome-build revision 462
glib-2.0 version 2.14.1
gtk+-2.0 version 2.12.1
libgnomeui-2.0 version 2.20.0
libgnome-2.0 version 2.20.0
Comment 21 Johannes Schmid 2007-12-28 23:26:59 UTC
*** Bug 501771 has been marked as a duplicate of this bug. ***
Comment 22 Sébastien Granjoux 2007-12-31 09:52:03 UTC
(In reply to comment #20)
> I have tried to reproduce the bug on my computer using the procedure given by
> Massimo but I don't get a crash.
> 
> I'm using:
> gdl revision 399
> anjuta revision 3382
> gnome-build revision 462
> glib-2.0 version 2.14.1
> gtk+-2.0 version 2.12.1
> libgnomeui-2.0 version 2.20.0
> libgnome-2.0 version 2.20.0

I have been able to get this problem by starting from an empty project. I suppose that the bug appears only if the bottom pane is not displayed.

Else, it seems that I get the segmentation fault in gtk_style_realize at the following line:
style->depth = gdk_colormap_get_visual (colormap)->depth;
colormap is NULL 

The problem seems to come from the window argument send to gtk_style_attach
gdk_drawable_get_colormap (window) return NULL. I think it explains the first critical errors.
Comment 23 Sébastien Granjoux 2007-12-31 17:04:38 UTC
I have spent some time trying to find exactly what's happen.

The bug in due to the label widgets (tab_label argument in GtkNotebook function) of the document manager notebook.

When a tab is moved in the document manager, these labels are set as children of a a new drag window (in gtknotebook.c:show_drag_window) and set back as children of the notebook when the drag operation end (in gtknotebook.c:hide_drag_window).

When a new message window needs to be displayed, gdl destroys all windows. The GdkWindow used by the label is destroyed and set to NULL in the label widget. Then, gdl recreates all the widgets (I suppose adding the new message widget) and here we get a call to gtk_widget_realize that is calling gtk_widget_get_parent_window to get the GdkWindow corresponding to the label. This function returns the old GdkWindow which still exist but is in destroyed state.

A bit later when gdk_drawable_get_colormap is called, it returns NULL (because the window is in destroyed state) explaining the first Gdk-Critical message. This case is not really handled by gtk, so it gives a few additional errors before the last segmentation fault.



I think, gtk_widget_get_parent_window shouldn't return the old window. It does it because gtk_notebook restores the previous parent with the following code:
  gtk_widget_set_parent_window (page->tab_label, widget->window);
  gtk_widget_set_parent (page->tab_label, widget);

I mean that the parent GdkWindow is set with gtk_widget_set_parent_window using a quark which overrides the default parent. It's not necessary here, because the  parent GtkWidget widget has the right GdkWindow.

Then, if this use of gtk_widget_set_parent_window is correct, the problem is rather in the function used to remove the parent of the label widget. I think it needs to remove this quark too.

Another solution is to handle a colormap = NULL in gtk_style_attach, but the first solution seems better.



I think the bug is in gtk and could be fix but just removing the call of gtk_widget_set_parent_window in notebook.c:hide_drag_window. I have tried here and it seems to work fine. Anyway, it's possible that this call is useful for another reason that I have missed.
Comment 24 Johannes Schmid 2008-01-06 00:24:19 UTC
Nice work Sébastien!

I would suggest you attach your proposed patch here and reassign the bug to gtk+ (where is was assigned to between comment #8 and comment #12). GTK+ developers tend to have a better look at bugs which have patches attached and will hopefully apply it or tell us that we are using a wrong solution. And Anjuta developers already fixed two bugs in this gtk+ release cycle! ;-)

What I am not sure about is that this bug also happens when no dragging takes place (see original report, so there may be other places where the problem with the parent window occurs which we might want to check. See comment #15, steps to reproduce two.

Thanks!
Comment 25 Sébastien Granjoux 2008-01-06 10:50:30 UTC
(In reply to comment #24)
> I would suggest you attach your proposed patch here and reassign the bug to
> gtk+ (where is was assigned to between comment #8 and comment #12). GTK+
> developers tend to have a better look at bugs which have patches attached and
> will hopefully apply it or tell us that we are using a wrong solution. And
> Anjuta developers already fixed two bugs in this gtk+ release cycle! ;-)

Ok. But could you check the things below before.

> What I am not sure about is that this bug also happens when no dragging takes
> place (see original report, so there may be other places where the problem with
> the parent window occurs which we might want to check. See comment #15, steps
> to reproduce two.

I have not been able to reproduce it without dragging (which is expected if I have really found the problem). Could you try it yourself ?

It's important that you start Anjuta and them try to do the second sequence immediately. The bug is triggered by dragging some tab, but can happen a long time later.

By example, if I start Anjuta, run compile, and then close the message tab. It's working fine. But if I start Anjuta, run compile, a message window appears correctly then drag a tab and close the message window, I get the bug like in the second sequence. But here, in all cases, dragging a tab is mandatory.
Comment 26 Johannes Schmid 2008-01-06 11:34:58 UTC
OK, it also happens for me when I drag around some of the GdlDockItems before pressing F11.

What just came into my mind is that gdl uses a GtkNotebook internally and that I may be the same bug you already found. So to reproduce you should maybe use a stock copy of GTK+ without your patch applied.

Thanks!
Comment 27 Sébastien Granjoux 2008-01-06 17:26:39 UTC
Ok, my current configuration uses button (added by Naba) instead of tab for Gdl window. It perhaps explains it's working here. I will try again using tab in Gdl.
Comment 28 Sébastien Granjoux 2008-01-07 08:26:16 UTC
I'm using a version of gtk+ with additional debugging message but without the fix and I don't get the error if I drag Gdl item.

It's a bit expected because according to my explanation, the bug is triggered only if you drag and drop a notebook tab and I think it's not possible to drag and drop Gdl tab. Or is it possible on your computer to change the Gdl tab order ? I'm currently using a patched version of gtk and I have loose some functionalities.

You get the bug even if you drag and drop a tab at the same place. So just clicking on a tab an moving a bit the mouse is enough to trigger the bug. When you drag and drop the project pane on the document pane, drag it back to the original place and then press F11, do you always get the bug or not ?

Another possibility is that you compiled a modified version of gtk (you just need to put in comment the line "gtk_widget_set_parent_window (page->tab_label, widget->window);" in gtk/gtknotebook.c in function hide_drag_window) and check if you still get a problem.

It's possible that there is in fact several bugs. 
Comment 29 Sébastien Granjoux 2008-01-15 18:49:52 UTC
Created attachment 102928 [details] [review]
fix

This patch fix the problem here, at least when the crash is triggered by a drag and drop of one document manager tab.
Comment 30 Naba Kumar 2008-01-15 20:43:11 UTC
Should we assign this bug to gtk+?
Comment 31 Sébastien Granjoux 2008-01-15 21:17:53 UTC
Here is a summary of my previous messages for gtk developers.

I have made more investigation about this bug. The window with the NULL colormap is the parent window of the Document manager tabs. It has a NULL colormap because this window is destroyed.

When a tab is dragged, its parent window is set (in gtknotebook.c: show_drag_window) as a drag window and its parent as the notebook. When it is dropped again, its parent window is set back (in gtknotebook.c: hide_drag_window) as the notebook window and its parent as the notebook.

The bug appears in gdl, because the parent of the tab is destroyed. The tabs are not destroy and get a new parent. But as the parent window has been set using gtk_widget_set_parent_window in hide_drag_window, changing the tab parent doesn't change the tab parent window. The tab has a correct parent but keeps the destroyed window as parent window.

I think it's not needed to set the parent window in hide_drag_window because it's already the window corresponding to the parent. Moreover, it seems strange to me that dragging a tab has such long lasting effect. I have written an obvious patch to fix this in the comment above.


Do you know a reason to use gtk_widget_set_parent_window in hide_drag_window ?

If needed, I will do more investigation to see if this can be fixed in gdl. Perhaps by overwriting the parent window when setting the new tab's parent.
Comment 32 Carlos Garnacho 2008-01-16 00:01:09 UTC
Thanks Sébastien for investigating this bug

(In reply to comment #31)
> 
> Do you know a reason to use gtk_widget_set_parent_window in hide_drag_window ?

The parent window is changed in show_drag_window(), so it must be reset back when hiding the drag window, but maybe it's not necessary to call gtk_window_set_parent_window() as gtk_widget_unparent() calls it already.

Maybe it's better to just call gtk_widget_set_parent_window() with parent_window = NULL to unset it? it's more clear to see what's happening if someone doesn't know such gtk_widget_unparent() details. Definitely setting parent_window to be explicitly widget->window is not the right way.
Comment 33 Sébastien Granjoux 2008-01-16 18:31:35 UTC
(In reply to comment #32)
> but maybe it's not necessary to call
> gtk_window_set_parent_window() as gtk_widget_unparent() calls it already.
> Maybe it's better to just call gtk_widget_set_parent_window() with
> parent_window = NULL to unset it?

I think gtk_container_remove calls gtk_widget_unparent which calls itself gtk_widget_set_parent_window with parent_window = NULL. So, in both cases, there is no need to call gtk_widget_set_parent_window again, just gtk_widget_set_parent should be enough.
Comment 34 Johannes Schmid 2008-01-24 20:42:29 UTC
*** Bug 511883 has been marked as a duplicate of this bug. ***
Comment 35 Johannes Schmid 2008-01-31 09:56:28 UTC
*** Bug 513332 has been marked as a duplicate of this bug. ***
Comment 36 Johannes Schmid 2008-02-09 23:53:55 UTC
*** Bug 515396 has been marked as a duplicate of this bug. ***
Comment 37 Sébastien Granjoux 2008-02-12 20:21:38 UTC
Created attachment 105085 [details]
test case for this bug

I have tried to write a simple test case without using gdl. It is crashing like it has been reported with 3 critical errors.

The bugs really comes from the parent window of the notebook tab label that is set to the notebook window at the end of the drag operation and is not removed when the window is destroyed.

Should I do something else to get the fix in the next release of gtk ?
Comment 38 Johannes Schmid 2008-02-18 11:17:35 UTC
*** Bug 517189 has been marked as a duplicate of this bug. ***
Comment 39 Johannes Schmid 2008-02-19 19:43:23 UTC
*** Bug 517518 has been marked as a duplicate of this bug. ***
Comment 40 Johannes Schmid 2008-03-06 11:08:17 UTC
*** Bug 520716 has been marked as a duplicate of this bug. ***
Comment 41 Johan (not receiving bugmail) Dahlin 2008-03-06 11:31:37 UTC
Carlos: Ping? Is the patch good to go in?

Sébastien: Can the test be written in such a way that it can be regression tested non-interactively, Eg, just run it and it will crash (and work with the patch applied) ?
Comment 42 Carlos Garnacho 2008-03-06 12:44:51 UTC
Yeah, the patch completely makes sense to me. I think it would be hard to test non-interactively, as that code is triggered from the drag and drop methods.
Comment 43 Johannes Schmid 2008-03-07 08:37:51 UTC
*** Bug 520925 has been marked as a duplicate of this bug. ***
Comment 44 Johannes Schmid 2008-03-07 08:52:46 UTC
*** Bug 517327 has been marked as a duplicate of this bug. ***
Comment 45 Sébastien Granjoux 2008-03-08 14:35:07 UTC
I don't know how to write this test in a non-interactive way.

I can try to use XWrapPointer and XSendEvent functions but as gtk is not working only on X Window, it's probably not the best idea.

Then, I can try to use gdk_display_put_event and add fake events in the queue to mimic the drag and drop operation but I don't know if it can work and which events should I push.


Comment 46 Johannes Schmid 2008-04-04 08:04:59 UTC
*** Bug 526077 has been marked as a duplicate of this bug. ***
Comment 47 Matthias Clasen 2008-04-10 01:46:54 UTC
Patch looks right to me too.

Carlos, we should get this committed to both branches.
Comment 48 Carlos Garnacho 2008-04-10 17:19:34 UTC
Thanks! Just committed the patch to both trunk and gtk-2-12.

2008-04-10  Carlos Garnacho  <carlos@imendio.com>

        * gtk/gtknotebook.c (hide_drag_window): Do not call
        gtk_widget_set_parent_window(), using widget->window instead of NULL
        to unset is the wrong thing, and gtk_widget_unparent() will already 
        take care of this (#467698, patch by Sébastien Granjoux)
Comment 49 Johannes Schmid 2008-04-16 07:09:08 UTC
*** Bug 528303 has been marked as a duplicate of this bug. ***
Comment 50 Johannes Schmid 2008-04-16 07:09:21 UTC
*** Bug 528316 has been marked as a duplicate of this bug. ***
Comment 51 Johannes Schmid 2008-04-25 08:14:40 UTC
*** Bug 529752 has been marked as a duplicate of this bug. ***
Comment 52 Johannes Schmid 2008-05-03 08:17:26 UTC
*** Bug 531144 has been marked as a duplicate of this bug. ***
Comment 53 Johannes Schmid 2008-05-05 23:45:16 UTC
*** Bug 531567 has been marked as a duplicate of this bug. ***
Comment 54 Johannes Schmid 2008-05-05 23:45:29 UTC
*** Bug 531618 has been marked as a duplicate of this bug. ***
Comment 55 Johannes Schmid 2008-05-13 09:11:28 UTC
*** Bug 532894 has been marked as a duplicate of this bug. ***
Comment 56 Johannes Schmid 2008-05-14 08:34:11 UTC
*** Bug 533001 has been marked as a duplicate of this bug. ***
Comment 57 Johannes Schmid 2008-05-14 10:19:45 UTC
*** Bug 533078 has been marked as a duplicate of this bug. ***
Comment 58 Johannes Schmid 2008-05-21 13:19:27 UTC
*** Bug 534183 has been marked as a duplicate of this bug. ***
Comment 59 Johannes Schmid 2008-06-22 10:41:18 UTC
*** Bug 539572 has been marked as a duplicate of this bug. ***