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.