GNOME Bugzilla – Bug 513944
Assertion: gtk_paint_vline() being called with style and window with different depths
Last modified: 2009-01-28 01:42:16 UTC
Metacity trunk (with or without the compositor) cyclical crash after swithing from a generic theme to Atlanta or Glider or Mist theme. Steps: 1. Open Appearance capplet -> Details 2. Go to window border tab 3. Select Atlanta/Glider/Mist Results: Metacity start to crash/restart/crash/restart/crash/restart/... Additional info: Startint metacity from a terminal window, the debug message after the theme change is: Log level 10: gtk_paint_vline: assertion `style->depth == gdk_drawable_get_depth (window)' failed Other themes seems uneffected.
Can't reproduce at all here. What theme are you starting from? Is the stable branch affected or just trunk?
(In reply to comment #1) > Can't reproduce at all here. What theme are you starting from? Mostly Clearlooks, but there is no difference starting from other themes like Esco, Bright or Crux. > Is the stable branch affected or just trunk? trunk (well, gnome-2-22 now) compiled with jhbuild. It could be some G_LOG_LEVEL_CRITICAL catched by gnome-session in odd (number) releases. I tried to run metacity in gdb (yeah, crazy) and I've: [New Thread -1220516176 (LWP 22783)] Window manager warning: Log level 10: gtk_paint_vline: assertion `style->depth == gdk_drawable_get_depth (window)' failed Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread -1220516176 (LWP 22783)] 0xb7741b4b in IA__g_logv (log_domain=<value optimized out>, log_level=G_LOG_LEVEL_CRITICAL, format=0xb7792c0a "%s: assertion `%s' failed", args1=0xbffc87dc "0�������`���@~\024\b\001") at gmessages.c:493 493 G_BREAKPOINT (); PS I've also tried to run metacity in gdb from console, but it simply freezes with no crash, so I'm unable to get the stacktrace by now.
Ah, that does make sense. So it's probably an assertion which is off in debug builds, so we never see it. I'll try tracking that down.
Luca: For future reference, running metacity under gdb is likely to mean you have to restart X (because metacity is still running when gdb pauses it at the instant of assertion failure, and therefore no new metacity is spawned). A better plan is here: http://blogs.gnome.org/metacity/2008/03/07/logging/
I experienced this same problem today (though it was in a debug build, so I only saw a lot of assertion failure messages rather than a crash). I can't seem to repeat it, though. I can confirm that I saw it both in gtk_paint_vline and gtk_paint_vline and gtk_paint_arrow. These are called identically in different limbs of the same case statemnt, anyhow. The case statement concerned is in meta_draw_op_draw_with_env(), and the problem is that the GdkDrawable called "drawable" and the "style" field of the GtkWidget called "widget" have different bit-per-pixel depths, which isn't allowed. These two variables are formal parameters of that function. MDODWE is either called from meta_draw_op_draw or meta_draw_op_list_draw. Both likewise pass the parameters straight through. From a brief search around, most of these seem to end up in meta_frames_paint_to_drawable in frames.c. That's as far as I'm going to look tonight, because I'm sleepy and it's getting late.
I'm rather stumped here because I'm reaching the edges of my knowledge of GTK. When the theme-drawing operations in meta_draw_op_draw_with_env() draw things, they get the style to use from the "style" field of "widget", but draw on "drawable". widget here is the MetaFrames inside the MetaUI inside the current MetaScreen, whereas "drawable" is a pixbuf based on the current window. The depth of the window that widget->style is attached to is therefore constant across a whole screen, but the depth of "drawable" can vary. It's not uncommon for widget->style's window to be 24-bit and drawable to be 32-bit. It is an undocumented requirement of gtk_paint_arrow() and other primitives that the style and the drawable have the same depth. What, then, is to be done? Should we pass in a style from the window somehow?
Looks like we may have a solution... *** This bug has been marked as a duplicate of 568365 ***