*** Bug 473068 has been marked as a duplicate of this bug. ***

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?)

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.

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.

OK, installed gtk+ with debugging symbols from Ubuntu feisty:

+ Trace 161642

    detail=0, 
    var_args=0xbf8fb170 "��<�H\227L�\230�\217\001lj

+ Trace 161862

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.

*** Bug 469735 has been marked as a duplicate of this bug. ***

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!

*** Bug 477257 has been marked as a duplicate of this bug. ***

*** Bug 476534 has been marked as a duplicate of this bug. ***

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

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?

*** Bug 492211 has been marked as a duplicate of this bug. ***

For me, this seems to be fixed with gtk+ 2.10 and gdl trunk. Can someone confirm this?

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.

+ Trace 179466

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

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

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().

*** Bug 501279 has been marked as a duplicate of this bug. ***

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):

+ Trace 180821

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.

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

*** Bug 501771 has been marked as a duplicate of this bug. ***

(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.

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.

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!

(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.

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!

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.

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. 

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.

Should we assign this bug to gtk+?

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.

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.

(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.

*** Bug 511883 has been marked as a duplicate of this bug. ***

*** Bug 513332 has been marked as a duplicate of this bug. ***

*** Bug 515396 has been marked as a duplicate of this bug. ***

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 ?

*** Bug 517189 has been marked as a duplicate of this bug. ***

*** Bug 517518 has been marked as a duplicate of this bug. ***

*** Bug 520716 has been marked as a duplicate of this bug. ***

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) ?

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.

*** Bug 520925 has been marked as a duplicate of this bug. ***

*** Bug 517327 has been marked as a duplicate of this bug. ***

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.

*** Bug 526077 has been marked as a duplicate of this bug. ***

Patch looks right to me too.

Carlos, we should get this committed to both branches.

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)

*** Bug 528303 has been marked as a duplicate of this bug. ***

*** Bug 528316 has been marked as a duplicate of this bug. ***

*** Bug 529752 has been marked as a duplicate of this bug. ***

*** Bug 531144 has been marked as a duplicate of this bug. ***

*** Bug 531567 has been marked as a duplicate of this bug. ***

*** Bug 531618 has been marked as a duplicate of this bug. ***

*** Bug 532894 has been marked as a duplicate of this bug. ***

*** Bug 533001 has been marked as a duplicate of this bug. ***

*** Bug 533078 has been marked as a duplicate of this bug. ***

*** Bug 534183 has been marked as a duplicate of this bug. ***

*** Bug 539572 has been marked as a duplicate of this bug. ***