GNOME Bugzilla – Bug 597101
Does not start anymore since 2.28.0. CRITICAL **: panel_multiscreen_x: assertion `monitor >= 0 && monitor < monitors
Last modified: 2009-10-06 10:59:22 UTC
Dear GNOME hackers, this is Debian bug 549180 [1]. I upgraded to 2.28.0 yesterday and the panel did not show up. Downgrading to 2.26.3 helped to get the GNOME panel back. I see the following error in .xsessionerros ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_x: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_y: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_height: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_x: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed ** (gnome-panel:3904): CRITICAL **: panel_multiscreen_y: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed Josselin Mouette asked me some questions, which I answererd. > Do you have a dual monitor setup? No, I do not. > Can you run the following Python code and show the output? from gtk import gdk display=gdk.display_get_default() n=display.get_n_screens() print n for i in range(n): screen=display.get_screen(i) print screen.get_width(), screen.get_height() $ python panel.py 1 1280 1024 If I can help further debugging this, please tell me how. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549180
A few questions: + do the errors from ~/.xsession-errors come from 2.28.0 or 2.26.3 (I would expect 2.26.3)? + did you ever use more than one monitor? + can you attach the output of "gconftool-2 -R /apps/panel/toplevels"?
(In reply to comment #1) > A few questions: > > + do the errors from ~/.xsession-errors come from 2.28.0 or 2.26.3 (I would > expect 2.26.3)? No, it is coming from 2.28.0. With 2.26.3 I do not have any gnome-panel related messages in ~/.xsession-errrors. > + did you ever use more than one monitor? No, I did not. > + can you attach the output of "gconftool-2 -R /apps/panel/toplevels"? $ gconftool-2 -R /apps/panel/toplevels # This is with 2.26.3. /apps/panel/toplevels/panel_0: enable_arrows = true enable_buttons = false hide_delay = 500 enable_animations = true unhide_delay = 500 size = 24 name = expand = true y_centered = false x_centered = false x_right = -1 screen = 0 animation_speed = medium monitor = 0 auto_hide_size = 6 x = 0 y = 0 y_bottom = -1 auto_hide = false orientation = top /apps/panel/toplevels/panel_0/background: opacity = 6000 rotate = false type = gtk color = #ffffff image = fit = false stretch = false /apps/panel/toplevels/bottom_panel_screen0: enable_arrows = true enable_buttons = false hide_delay = 500 enable_animations = true unhide_delay = 500 name = size = 24 expand = true y_centered = false x_centered = false screen = 0 monitor = 0 auto_hide_size = 6 x = 0 y = 0 orientation = bottom auto_hide = false /apps/panel/toplevels/bottom_panel_screen0/background: opacity = 6000 rotate = false type = gtk color = #ffffff image = fit = false stretch = false
So you have two panels, and both are on screen 0 and monitor 0. So I don't really understand how you could get those warnings :/ To know what's going on, you'd need to fire gnome-panel in gdb, and look at the value of monitor during the panel_multiscreen_width()/panel_multiscreen_height() calls. Is this something you can do?
(or recompile gnome-panel with some g_print() debug statements)
Just to double check everything is fine with gtk+, can you run this updated python script: from gtk import gdk display=gdk.display_get_default() n=display.get_n_screens() print '%d screen(s)' % n for i in range(n): print 'Screen %d: ' % i screen=display.get_screen(i) m = screen.get_n_monitors() print ' %d monitor(s)' % m for j in range(m): geo = screen.get_monitor_geometry(j) print ' ', geo
(In reply to comment #5) > Just to double check everything is fine with gtk+, can you run this updated > python script: > > from gtk import gdk > display=gdk.display_get_default() > n=display.get_n_screens() > print '%d screen(s)' % n > for i in range(n): > print 'Screen %d: ' % i > screen=display.get_screen(i) > m = screen.get_n_monitors() > print ' %d monitor(s)' % m > for j in range(m): > geo = screen.get_monitor_geometry(j) > print ' ', geo 1 screen(s) Screen 0: 1 monitor(s) gtk.gdk.Rectangle(0, 0, 1280, 1024)
I noticed two more things. I upgraded to 2.28.0 again today. Logging in, I had the same problem. Switching to a different user, this user did not experience the problem on the same system. This user’s ~/.xsession-errors had no CRITICAL messages inside. I attached to gnome-panel with gdb and issued `bt full`. 0xf7fac425 in __kernel_vsyscall () (gdb) bt full
+ Trace 218015
But this looks useless to you, since comparing the files shows, that just the addresses(?) differ and everything else is the same. $ diff -u gdbp.1 gdbp.2 --- gdbp.1 2009-10-03 11:19:39.000000000 +0200 +++ gdbp.2 2009-10-03 11:19:54.000000000 +0200 @@ -1,40 +1,39 @@ -0xf7fac425 in __kernel_vsyscall () +0xf7f79425 in __kernel_vsyscall () (gdb) bt full -#0 0xf7fac425 in __kernel_vsyscall () +#0 0xf7f79425 in __kernel_vsyscall () No symbol table info available. -#1 0xf748142b in *__GI___poll (fds=0x9a688c8, nfds=14, timeout=4000) +#1 0xf744e42b in *__GI___poll (fds=0x84e5850, nfds=14, timeout=3998) at ../sysdeps/unix/sysv/linux/poll.c:83 resultvar = <value optimized out> oldtype = <value optimized out> result = <value optimized out> -#2 0xf76746cb in IA__g_poll (fds=0x9a688c8, nfds=14, timeout=4000) +#2 0xf76416cb in IA__g_poll (fds=0x84e5850, nfds=14, timeout=3998) at /build/buildd-glib2.0_2.22.1-1-i386-tx7y62/glib2.0-2.22.1/glib/gpoll.c:127 No locals. -#3 0xf76674f5 in g_main_context_poll (context=0x9842850, block=1, dispatch=1, - self=0x9813220) +#3 0xf76344f5 in g_main_context_poll (context=0x81b2850, block=1, dispatch=1, + self=0x8183220) at /build/buildd-glib2.0_2.22.1-1-i386-tx7y62/glib2.0-2.22.1/glib/gmain.c:2904 No locals. -#4 g_main_context_iterate (context=0x9842850, block=1, dispatch=1, - self=0x9813220) +#4 g_main_context_iterate (context=0x81b2850, block=1, dispatch=1, + self=0x8183220) at /build/buildd-glib2.0_2.22.1-1-i386-tx7y62/glib2.0-2.22.1/glib/gmain.c:2586 max_priority = 2147483647 - timeout = 4000 + timeout = 3998 some_ready = <value optimized out> ----Type <return> to continue, or q <return> to quit--- nfds = 14 allocated_nfds = <value optimized out> - fds = 0x9a688c8 + fds = 0x84e5850 __PRETTY_FUNCTION__ = "g_main_context_iterate" -#5 0xf7667aea in IA__g_main_loop_run (loop=0x9910230) +#5 0xf7634aea in IA__g_main_loop_run (loop=0x8282538) at /build/buildd-glib2.0_2.22.1-1-i386-tx7y62/glib2.0-2.22.1/glib/gmain.c:2799 - self = 0x9813220 + self = 0x8183220 __PRETTY_FUNCTION__ = "IA__g_main_loop_run" -#6 0xf7b15eb9 in IA__gtk_main () +#6 0xf7ae2eb9 in IA__gtk_main () at /build/buildd-gtk+2.0_2.18.1-1-i386-d2TqLS/gtk+2.0-2.18.1/gtk/gtkmain.c:1205 tmp_list = 0x1 functions = 0x0 - init = 0xfffe6384 - loop = 0x9910230 -#7 0x08063a7a in main (argc=1, argv=0xfffe6384) at main.c:108 + init = 0xfff1eab4 + loop = 0x8282538 +#7 0x08063a7a in main (argc=1, argv=0xfff1eab4) at main.c:108 context = <value optimized out> program = <value optimized out> So to summarize. 1. GNOME panel 2.28.0 works for a *different* user on the *same* system. 2. GNOME panel 2.28.0 works for me, if I kill it and it is restarted.
(In reply to comment #3) > So you have two panels, and both are on screen 0 and monitor 0. So I don't > really understand how you could get those warnings :/ > > To know what's going on, you'd need to fire gnome-panel in gdb, and look at the > value of monitor during the > panel_multiscreen_width()/panel_multiscreen_height() calls. Is this something > you can do? Thanks to search engines and your helpful answers on gnome-bugsquad [1] I try to debug it. Unfortunately `gnome-session-remove` appears not to exist anymore. Could you please update [2][3]. A link to [3] would help next time a million too, when [3] is updated. ;-) So I tried to remove `gnome-panel` in gnome-session-proporties [3] but could not find it there. Could you give me a hint please, how I can do that. Thanks, Paul [1] http://mail.gnome.org/archives/gnome-bugsquad/2005-May/msg00019.html [2] http://live.gnome.org/MemoryReduction/Tools/GetValgrindInToughPlaces?highlight=%28gnome%5C-session%5C-remove%29 [3] http://live.gnome.org/Bugsquad/TriageGuide/ProductSpecificGuidelines
(In reply to comment #7) […] > So to summarize. > > 1. GNOME panel 2.28.0 works for a *different* user on the *same* system. > 2. GNOME panel 2.28.0 works for me, if I kill it and it is restarted. 3. Logging out and back in GNOME panel does not startup again. I tried to kill it with `kill <pid>` several times and the process restarted but did not show up. Only when I issued `killall gnome-panel` GNOME panel started up correctly. Strange. I do not know what command I issued in comment #7.
Ah, well, gnome-session-remove doesn't exist anymore. However, you can start a new panel with "gnome-panel --replace". In gdb, this would be: gdb gnome-panel (gdb) set args --replace (gdb) run However, to get the information I need in this case, you'd need to set breakpoints before "run". You can do it this way. (gdb) br panel_multiscreen_width (gdb) br panel_multiscreen_height And then, once the panel running, gdb will interrupt the panel when those function are called. You can then do: (gdb) print monitor This will display the value of the monitor variable. You can also do the "next", "continue" commands to go to the next instruction or to let the application continue until the next breakpoint. Or you can use the "disable" command to disable a specific breakpoint ("disable 1" will disable the first one).
(In reply to comment #10) > Ah, well, gnome-session-remove doesn't exist anymore. However, you can start a > new panel with "gnome-panel --replace". Perfect. Thank you! Also thank you for updating this on the web pages. On [2] and on [3] Nautilus CD-Burner is still written `gnome-session-remove`. I cannot use my Bugzilla account for this. > In gdb, this would be: [Explanation on how to use gdb for debugging.] Thank you for the explanation. It looks like the monitor array(?) has only 0 written as values and therefore the check fails in my case. (gdb) set args --replace (gdb) break panel_multiscreen_width Breakpoint 1 at 0x80a1657: file panel-multiscreen.c, line 553. (gdb) break panel_multiscreen_height Breakpoint 2 at 0x80a15b7: file panel-multiscreen.c, line 567. (gdb) run Starting program: /usr/bin/gnome-panel --replace […] (gdb) continue Continuing. Breakpoint 1, panel_multiscreen_width (screen=0x80ee108, monitor=0) at panel-multiscreen.c:553 553 in panel-multiscreen.c (gdb) next 550 in panel-multiscreen.c (gdb) print monitor $9 = 0 (gdb) next 553 in panel-multiscreen.c (gdb) print monitor $10 = 0 (gdb) next 555 in panel-multiscreen.c (gdb) print monitor $11 = 0 (gdb) next 553 in panel-multiscreen.c (gdb) print monitor $12 = 0 (gdb) next 555 in panel-multiscreen.c (gdb) print monitor $13 = 0 (gdb) next 556 in panel-multiscreen.c (gdb) print monitor $14 = 0 (gdb) next ** (gnome-panel:15418): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed 559 in panel-multiscreen.c (gdb) print monitor $15 = 0 (gdb) print monitors $16 = (int *) 0x8131610 (gdb) print n_screen $17 = <value optimized out> (gdb) print monitors[1] $18 = 0 (gdb) print monitors[0] $19 = 0 (gdb) print monitors[2] $20 = 0 (gdb) print monitors[3] $21 = 25 (gdb) print monitors[4] $22 = 135219368 Thanks, Paul
Thanks, very useful stuff. See below. (In reply to comment #11) > ** (gnome-panel:15418): CRITICAL **: panel_multiscreen_width: assertion > `monitor >= 0 && monitor < monitors [n_screen]' failed > 559 in panel-multiscreen.c > (gdb) print monitor > $15 = 0 > (gdb) print monitors > $16 = (int *) 0x8131610 > (gdb) print n_screen > $17 = <value optimized out> > (gdb) print monitors[1] > $18 = 0 > (gdb) print monitors[0] > $19 = 0 Assuming those values can be trusted, this is where we have an issue. monitors[0] should be 1, not 0. We're getting there. Can you put a breakpoint on panel_multiscreen_get_monitors_for_screen() and print the value of "*monitors_ret" (note the * at the beginning) at various points there? This would be something like: (gdb) br panel_multiscreen_get_monitors_for_screen (gdb) run ... (gdb) print *monitors_ret (gdb) next (gdb) print *monitors_ret (gdb) next (gdb) print *monitors_ret (should work fine, although it's hard to do some remote gdb like this ;-)) Also, maybe attach the output of "xrandr --verbose". Just wondering if this could be an issue with your graphic driver.
Thank you for always answering so quickly and giving instructions to me. (In reply to comment #12) > We're getting there. Can you put a breakpoint on > panel_multiscreen_get_monitors_for_screen() and print the value of > "*monitors_ret" (note the * at the beginning) at various points there? > > This would be something like: > (gdb) br panel_multiscreen_get_monitors_for_screen That does not work unfortunately for me. (gdb) set args --replace (gdb) br panel_multiscreen_get_monitors_for_screen Function "panel_multiscreen_get_monitors_for_screen" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (panel_multiscreen_get_monitors_for_screen) pending. (gdb) run Starting program: /usr/bin/gnome-panel --replace [Thread debugging using libthread_db enabled] ** (gnome-panel:26034): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed [… until I press Ctrl + c] […] > Also, maybe attach the output of "xrandr --verbose". Just wondering if this > could be an issue with your graphic driver. Spot on! I can start `gnome-panel` reliably if I issue `xrandr --verbose` beforehand. So something must have changed in gnome-panel or libgnome2-0, since downgrading to 2.26.3 helped independently from the graphics driver. [DEAKTUALISIERUNG] gnome-panel 2.28.0-1 -> 2.26.3-1 [DEAKTUALISIERUNG] gnome-panel-data 2.28.0-1 -> 2.26.3-1 [DEAKTUALISIERUNG] gnome-panel-dbg 2.28.0-1 -> 2.26.3-1 [DEAKTUALISIERUNG] libgnome2-0 2.28.0-1 -> 2.26.0-1 [DEAKTUALISIERUNG] libgnome2-common 2.28.0-1 -> 2.26.0-1 [DEAKTUALISIERUNG] libgnome2-dbg 2.28.0-1 -> 2.26.0-1 [DEAKTUALISIERUNG] libgnome2-dev 2.28.0-1 -> 2.26.0-1 [DEAKTUALISIERUNG] libpanel-applet2-0 2.28.0-1 -> 2.26.3-1 Just in case, here is the output from `xrandr --verbose`. $ xrandr --verbose Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024 default connected 1280x1024+0+0 (0x112) normal (normal) 0mm x 0mm Identifier: 0x111 Timestamp: 16846860 Subpixel: no subpixels Clones: CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 1280x1024 (0x112) 78.6MHz *current h: width 1280 start 0 end 0 total 1280 skew 0 clock 61.4KHz v: height 1024 start 0 end 0 total 1024 clock 60.0Hz 1280x1024 (0x113) 98.3MHz h: width 1280 start 0 end 0 total 1280 skew 0 clock 76.8KHz v: height 1024 start 0 end 0 total 1024 clock 75.0Hz 1280x960 (0x114) 73.7MHz h: width 1280 start 0 end 0 total 1280 skew 0 clock 57.6KHz v: height 960 start 0 end 0 total 960 clock 60.0Hz 1152x864 (0x115) 74.6MHz h: width 1152 start 0 end 0 total 1152 skew 0 clock 64.8KHz v: height 864 start 0 end 0 total 864 clock 75.0Hz 1152x864 (0x116) 69.7MHz h: width 1152 start 0 end 0 total 1152 skew 0 clock 60.5KHz v: height 864 start 0 end 0 total 864 clock 70.0Hz 1152x864 (0x117) 59.7MHz h: width 1152 start 0 end 0 total 1152 skew 0 clock 51.8KHz v: height 864 start 0 end 0 total 864 clock 60.0Hz 1024x768 (0x118) 59.0MHz h: width 1024 start 0 end 0 total 1024 skew 0 clock 57.6KHz v: height 768 start 0 end 0 total 768 clock 75.0Hz 1024x768 (0x119) 55.1MHz h: width 1024 start 0 end 0 total 1024 skew 0 clock 53.8KHz v: height 768 start 0 end 0 total 768 clock 70.0Hz 1024x768 (0x11a) 47.2MHz h: width 1024 start 0 end 0 total 1024 skew 0 clock 46.1KHz v: height 768 start 0 end 0 total 768 clock 60.0Hz 832x624 (0x11b) 38.9MHz h: width 832 start 0 end 0 total 832 skew 0 clock 46.8KHz v: height 624 start 0 end 0 total 624 clock 75.0Hz 800x600 (0x11c) 36.0MHz h: width 800 start 0 end 0 total 800 skew 0 clock 45.0KHz v: height 600 start 0 end 0 total 600 clock 75.0Hz 800x600 (0x11d) 34.6MHz h: width 800 start 0 end 0 total 800 skew 0 clock 43.2KHz v: height 600 start 0 end 0 total 600 clock 72.0Hz 800x600 (0x11e) 28.8MHz h: width 800 start 0 end 0 total 800 skew 0 clock 36.0KHz v: height 600 start 0 end 0 total 600 clock 60.0Hz 800x600 (0x11f) 26.9MHz h: width 800 start 0 end 0 total 800 skew 0 clock 33.6KHz v: height 600 start 0 end 0 total 600 clock 56.0Hz 640x480 (0x120) 23.0MHz h: width 640 start 0 end 0 total 640 skew 0 clock 36.0KHz v: height 480 start 0 end 0 total 480 clock 75.0Hz 640x480 (0x121) 22.4MHz h: width 640 start 0 end 0 total 640 skew 0 clock 35.0KHz v: height 480 start 0 end 0 total 480 clock 73.0Hz 640x480 (0x122) 20.6MHz h: width 640 start 0 end 0 total 640 skew 0 clock 32.2KHz v: height 480 start 0 end 0 total 480 clock 67.0Hz 640x480 (0x123) 18.4MHz h: width 640 start 0 end 0 total 640 skew 0 clock 28.8KHz v: height 480 start 0 end 0 total 480 clock 60.0Hz 720x400 (0x124) 20.2MHz h: width 720 start 0 end 0 total 720 skew 0 clock 28.0KHz v: height 400 start 0 end 0 total 400 clock 70.0Hz
(cc'ing Josselin who can possibly help provide a test package, and Federico for a randr question) (In reply to comment #13) > > This would be something like: > > (gdb) br panel_multiscreen_get_monitors_for_screen > > That does not work unfortunately for me. > > (gdb) set args --replace > (gdb) br panel_multiscreen_get_monitors_for_screen > Function "panel_multiscreen_get_monitors_for_screen" not defined. > Make breakpoint pending on future shared library load? (y or [n]) y Huh. That's surprising. It should really be there :/ > > Also, maybe attach the output of "xrandr --verbose". Just wondering if this > > could be an issue with your graphic driver. > > Spot on! I can start `gnome-panel` reliably if I issue `xrandr --verbose` > beforehand. So something must have changed in gnome-panel or libgnome2-0, since > downgrading to 2.26.3 helped independently from the graphics driver. Ahah! That's interesting. Federico: is it possible that calling xrandr initializes something that we would need? Josselin, can you possibly make a new package with the patch I'm going to attach (it's a guess-attempt to fix it)
Created attachment 144668 [details] [review] Fallback to gtk API if randr doesn't give us any monitor
(In reply to comment #14) […] > Josselin, can you possibly make a new package with the patch I'm going to > attach (it's a guess-attempt to fix it) Josselin, I think, I can build a package with the patch applied myself. No work for you. I will report back.
(In reply to comment #16) > (In reply to comment #14) > > […] > > > Josselin, can you possibly make a new package with the patch I'm going to > > attach (it's a guess-attempt to fix it) > > Josselin, I think, I can build a package with the patch applied myself. No work > for you. > > I will report back. I build the packages and it works like a charme after a quick test. Thanks!!!
Good to know the patch helps. Still trying to figure out why this is happening... (In reply to comment #13) > $ xrandr --verbose > Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024 > default connected 1280x1024+0+0 (0x112) normal (normal) 0mm x 0mm Ahah! The output is named "default". In our code, we have: /* Drivers before RANDR 1.2 return "default" for the output * name */ if (g_strcmp0 (output->name, "default") == 0) driver_is_pre_randr_1_2 = TRUE; And in this case, we ignore the randr data, so we should already fallback to the gtk code. This is obviously not happening. And I have no idea why. Paul, do you have some more time to help there? You'd need to use gdb with a breakpoint in panel_multiscreen_get_randr_monitors_for_screen() and see if we set driver_is_pre_randr_1_2 to TRUE. Else, is there any way for me to make Xephyr pretends it's using randr 1.1 or earlier?
(In reply to comment #18) […] > Paul, do you have some more time to help there? Sure I try to. > You'd need to use gdb with a breakpoint in > panel_multiscreen_get_randr_monitors_for_screen() and see if we set > driver_is_pre_randr_1_2 to TRUE. I downgraded to the version without the patch again. (Is that needed?) Sorry, gdb still cannot handle this breakpoint. I do not know why. I have the debugging symbols installed using gnome-panel-dbg. Could there be an error? Do I need other debuging symbols? (gdb) set args --replace (gdb) br panel_multiscreen_get_randr_monitors_for_screen Function "panel_multiscreen_get_randr_monitors_for_screen" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (panel_multiscreen_get_randr_monitors_for_screen) pending. (gdb) run Starting program: /usr/bin/gnome-panel --replace [Thread debugging using libthread_db enabled] ** (gnome-panel:10775): CRITICAL **: panel_multiscreen_width: assertion `monitor >= 0 && monitor < monitors [n_screen]' failed […]
I just wanted to point out again that the bug only surfaces if I log in with a certain user. Using a different user, GNOME panel works as expected.
Created attachment 144801 [details] [review] Debugging patch Paul: can you run gnome-panel with the attached patch in the account that has the issue? It will print some new debug information since I can't debug it on my computer. Then please attach the new output here. Note that it contains the fix, so you'll still be able to use your computer ;-) But it's important to run it where you had an issue so I get the right debug info. Thanks!
(In reply to comment #21) > Created an attachment (id=144801) [details] > Debugging patch > > Paul: can you run gnome-panel with the attached patch in the account that has > the issue? It will print some new debug information since I can't debug it on > my computer. > > Then please attach the new output here. Thank you for the patch. I had to fix the last hung, since the other patch was still applied to the source. I hope I did not screw up. $ gnome-panel --replace panel_multiscreen_get_raw_monitors_for_screen -- start panel_multiscreen_get_randr_monitors_for_screen -- start panel_multiscreen_get_randr_monitors_for_screen -- have randr panel_multiscreen_get_randr_monitors_for_screen -- have resources panel_multiscreen_get_randr_monitors_for_screen -- begin loop panel_multiscreen_get_randr_monitors_for_screen -- end loop panel_multiscreen_get_randr_monitors_for_screen -- return 0 panel_multiscreen_get_randr_monitors_for_screen -- randr returned 1 len=0 (gnome-panel:29191): Gdk-CRITICAL **: gdk_x11_colormap_foreign_new: assertion `GDK_IS_VISUAL (visual)' failed
(In reply to comment #22) > $ gnome-panel --replace > panel_multiscreen_get_raw_monitors_for_screen -- start > panel_multiscreen_get_randr_monitors_for_screen -- start > panel_multiscreen_get_randr_monitors_for_screen -- have randr > panel_multiscreen_get_randr_monitors_for_screen -- have resources > panel_multiscreen_get_randr_monitors_for_screen -- begin loop > panel_multiscreen_get_randr_monitors_for_screen -- end loop > panel_multiscreen_get_randr_monitors_for_screen -- return 0 > panel_multiscreen_get_randr_monitors_for_screen -- randr returned 1 len=0 Okay, we never get inside the loop, which means resources->noutput is 0. My guess is that this happens with a pre-randr 1.2 driver, but I'm not 100% sure.
(In reply to comment #23) > (In reply to comment #22) > > $ gnome-panel --replace > > panel_multiscreen_get_raw_monitors_for_screen -- start > > panel_multiscreen_get_randr_monitors_for_screen -- start > > panel_multiscreen_get_randr_monitors_for_screen -- have randr > > panel_multiscreen_get_randr_monitors_for_screen -- have resources > > panel_multiscreen_get_randr_monitors_for_screen -- begin loop > > panel_multiscreen_get_randr_monitors_for_screen -- end loop > > panel_multiscreen_get_randr_monitors_for_screen -- return 0 > > panel_multiscreen_get_randr_monitors_for_screen -- randr returned 1 len=0 > > Okay, we never get inside the loop, which means resources->noutput is 0. Ok, this is the output with the other user. $ gnome-panel --replace panel_multiscreen_get_raw_monitors_for_screen -- start panel_multiscreen_get_randr_monitors_for_screen -- start panel_multiscreen_get_randr_monitors_for_screen -- have randr panel_multiscreen_get_randr_monitors_for_screen -- have resources panel_multiscreen_get_randr_monitors_for_screen -- begin loop panel_multiscreen_get_randr_monitors_for_screen -- loop 0 panel_multiscreen_get_randr_monitors_for_screen -- is pre randr 1.2 panel_multiscreen_get_randr_monitors_for_screen -- has crtc panel_multiscreen_get_randr_monitors_for_screen -- end loop panel_multiscreen_get_randr_monitors_for_screen -- is pre randr 1.2 so FALSE panel_multiscreen_get_randr_monitors_for_screen -- randr returned 0 len=0 > My guess is that this happens with a pre-randr 1.2 driver, but I'm not 100% sure. I am using the Openchrome driver. I am not sure, [1] suggest it is a pre-randr 1.2 driver and [2] that the support is available. But I do not think it is in the Debian package. Anyway, the strange thing is still, why does it work with the other user. Does GDK(?) check some other user specific settings? What did change between GNOME panel 2.26.3 and 2.28.0? Do you have further ideas on how to proceed? [1] http://www.phoronix.com/forums/showthread.php?t=13968#post52656 [2] http://ubuntuforums.org/showthread.php?t=942402
(In reply to comment #24) > Ok, this is the output with the other user. > > $ gnome-panel --replace > panel_multiscreen_get_raw_monitors_for_screen -- start > panel_multiscreen_get_randr_monitors_for_screen -- start > panel_multiscreen_get_randr_monitors_for_screen -- have randr > panel_multiscreen_get_randr_monitors_for_screen -- have resources > panel_multiscreen_get_randr_monitors_for_screen -- begin loop > panel_multiscreen_get_randr_monitors_for_screen -- loop 0 > panel_multiscreen_get_randr_monitors_for_screen -- is pre randr 1.2 > panel_multiscreen_get_randr_monitors_for_screen -- has crtc > panel_multiscreen_get_randr_monitors_for_screen -- end loop > panel_multiscreen_get_randr_monitors_for_screen -- is pre randr 1.2 so FALSE > panel_multiscreen_get_randr_monitors_for_screen -- randr returned 0 len=0 Interesting, indeed. > > My guess is that this happens with a pre-randr 1.2 driver, but I'm not 100% sure. > > I am using the Openchrome driver. I am not sure, [1] suggest it is a pre-randr > 1.2 driver and > [2] that the support is available. But I do not think it is in the Debian > package. Good to know. > Anyway, the strange thing is still, why does it work with the other user. Does > GDK(?) check some other user specific settings? Can you do "gconftool-2 -R /apps/gnome_settings_daemon/plugins/xrandr" for both users? Also, can you attach ~/.config/monitors.xml for both users, if they have the file? > What did change between GNOME panel 2.26.3 and 2.28.0? We fixed the panel to better handle randr ;-) Turns out there are cases like yours where it doesn't work well ;-) At this point, I have a patch that I'll probably commit -- I just want to really understand why this happens so I'm sure it fixes all weird cases. Note that https://bugzilla.novell.com/show_bug.cgi?id=543876 is similar to your issue, except that in this case, all monitors appear disconnected...
(In reply to comment #25) > (In reply to comment #24) […] > > Anyway, the strange thing is still, why does it work with the other user. Does > > GDK(?) check some other user specific settings? > > Can you do "gconftool-2 -R /apps/gnome_settings_daemon/plugins/xrandr" for both > users? You are the man!!! # user with non-working setup $ gconftool-2 -R /apps/gnome_settings_daemon/plugins/xrandr priority = 1 active = false # user with working setup $ gconftool-2 -R /apps/gnome_settings_daemon/plugins/xrandr priority = 1 active = true And now I also remember that I changed it and when I did so. It was while debugging #583709. > Also, can you attach ~/.config/monitors.xml for both users, if they have > the file? I do not have it. […] Can you check somehow, if the plugin is enabled and print a warning? Or is GDK(?) responsible for that? I found a next problem I can deal with. ;-) $ gnome-settings-daemon ** (gnome-settings-daemon:19023): WARNING **: Failed to acquire org.gnome.SettingsDaemon ** (gnome-settings-daemon:19023): WARNING **: Could not acquire name
The plugin is only enabled if the gconf key is enabled. There's no log about it (and you can't restart g-s-d during the session since it's already running) Okay, I have the full picture now. What happend is that since the xrandr plugin of g-s-d is not active, nothing was calling XRRGetScreenResources. X is reporting that it supports randr 1.3 (that's not what your driver supports, that's what the X server supports), so we were calling XRRGetScreenResourcesCurrent, which just reuses the result of a previous XRRGetScreenResources call (I guess). So we got nothing. I'll attach the patch I'll commit, and you can ask it to be included in the Debian package.
Created attachment 144878 [details] [review] [panel] Fix crashes in various conditions with the new randr code If nothing had probed the randr screen resources before us and the X server is supporting randr 1.3, then we got no output, and therefore no monitor. The fix here is to actively probe for resources if we detect this case. See https://bugzilla.gnome.org/show_bug.cgi?id=597101 Also, in some cases, all outputs appear disconnected. See https://bugzilla.novell.com/show_bug.cgi?id=543876 To be completely on the safe side, if we get no monitor information from randr, even if it is successful, we fallback to the GTK+ method.
Paul: a big thank you for your help. I wouldn't have been able to identify the issue without you!
I’ve committed it to our repository as well. It will be included in the next upload to unstable. Thanks a lot to both of you.