xrandr-plugin-DEBUG: === xinerama setup Configuration ===
xrandr-plugin-DEBUG:   Clone: false
xrandr-plugin-DEBUG:   Output: Built-in Display attached to LVDS-1
xrandr-plugin-DEBUG:      status: on
xrandr-plugin-DEBUG:      width: 1920
xrandr-plugin-DEBUG:      height: 1080
xrandr-plugin-DEBUG:      rate: 60
xrandr-plugin-DEBUG:      primary: true
xrandr-plugin-DEBUG:      position: 0 0
xrandr-plugin-DEBUG:   Output: Unknown Display attached to HDMI-1
xrandr-plugin-DEBUG:      status: off
xrandr-plugin-DEBUG:      width: -1
xrandr-plugin-DEBUG:      height: -1
xrandr-plugin-DEBUG:      rate: -1
xrandr-plugin-DEBUG:      primary: false
xrandr-plugin-DEBUG:      position: -1 -1
xrandr-plugin-DEBUG:   Output: HSD 18" attached to DVI-I-1
xrandr-plugin-DEBUG:      status: on
xrandr-plugin-DEBUG:      width: 1920
xrandr-plugin-DEBUG:      height: 1080
xrandr-plugin-DEBUG:      rate: 60
xrandr-plugin-DEBUG:      primary: false
xrandr-plugin-DEBUG:      position: 0 0

Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so and reopen this bug or report a new one. 

Furthermore, the bug is lacking information such as:
- the exact version of the crashing component (gnome-settings-daemon and gnome-desktop would be useful)
- the driver used for the video output (Intel? NVidia? Other?)

And it looks like there should be other warnings beforehand.

That might fix it, but I don't see how there couldn't be warnings about invalid outputs beforehand.

diff --git a/plugins/xrandr/gsd-xrandr-manager.c b/plugins/xrandr/gsd-xrandr-manager.c
index a03018e..f249652 100644
--- a/plugins/xrandr/gsd-xrandr-manager.c
+++ b/plugins/xrandr/gsd-xrandr-manager.c
@@ -1097,7 +1097,7 @@ trim_rightmost_outputs_that_dont_fit_in_framebuffer (GnomeRRScreen *rr_screen, G
                 }
         }
 
-        qsort (sorted_outputs, num_on_outputs, sizeof (sorted_outputs[0]), compare_output_positions);
+        qsort (sorted_outputs, j, sizeof (sorted_outputs[0]), compare_output_positions);
 
         /* Trim! */

(In reply to comment #2)
> Thanks for taking the time to report this bug.

Thanks for your quick response.

> Unfortunately, that stack trace is missing some elements that will help a lot
> to solve the problem, so it will be hard for the developers to fix that crash.
>
> Can you get us a stack trace with debugging symbols? Please see
> http://live.gnome.org/GettingTraces for more information on how to do so and
> reopen this bug or report a new one. 

Okay, I'll try to do that.
 
> Furthermore, the bug is lacking information such as:
> - the exact version of the crashing component (gnome-settings-daemon and
> gnome-desktop would be useful)

Posted that in Whiteboard; but to be explicit, both are 3.8.3.

> - the driver used for the video output (Intel? NVidia? Other?)

This fails with both NVIDIA drivers and Nouveau.

> And it looks like there should be other warnings beforehand.

I don't remember any warnings form gnome-settings-daemon in either the console output or the journal; do you mean a warning from something else, because I do get this one:

gdm[11439]: Failed to give slave programs access to the display

I'm planning to file a separate bug for that one; not sure if I can do that now as that one requires quite some details and time, but I'll link both bugs with the See Also field once I have done that. 

(In reply to comment #3)
> That might fix it, but I don't see how there couldn't be warnings about invalid
> outputs beforehand.

Interesting, I'll try that soon; as stated above, there are indeed no warnings except for the gdm warning.

I'll comment again once I have more information (stack trace, patch, other bug).

Done, involved packages that introduce symbols recompiled with -O0 -ggdb (glibc with -O2 due to package manager; I can override and recompile again if needed, but looking at the trace it didn't optimize out anything important).

This yields:

Breakpoint 1, gnome_rr_output_info_get_geometry (self=0x1, x=0x4000000000000000, y=0x0, width=0xc000000000000000, height=0x0) at gnome-rr-output-info.c:106
106     in gnome-rr-output-info.c
(gdb) bt

+ Trace 232252

Continuing.

(gnome-settings-daemon:28897): GnomeDesktop-CRITICAL **: gnome_rr_output_info_get_geometry: assertion `GNOME_IS_RR_OUTPUT_INFO (self)' failed

As for the patch; no improvement, you can see that it fills in n=2 due to your change. What does that 2 mean? Please note that I am only using my laptop screen at this point with no external hardware connected. For completeness, here is my xrandr output with a short explanation of what is seen:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080      60.0*+   60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      59.9  
   1280x960       59.9  
   1152x864       60.0  
   1024x768       59.9  
   800x600        59.9  
   640x480        59.4  
   720x400        59.6  
   640x400        60.0  
   640x350        59.8  
HDMI-1 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 215mm
   1920x1080      60.0*+

I have a LVDS-0 which is my laptop panel, it is which is showing Screen 0. Then I have a physical HDMI-1 connector with nothing attached, it is therefore disconnected. Last, there is also a physical DVI-I-1 connector, with again nothing attached; but, since I think it shares the output with LVDS-1, it shows as connected.

Some time ago, when I attach a monitor I figured out it is a shared output, because I can either get output to show on one screen or the other or both simulatenously; but I can't get it to extend which means that it aren't separate outputs.

Not sure how relevant this is; but, maybe that might explain why n=2?

As a consequence of this, I also seem to be able to move my mouse past the screen edge to the right (as if a second screen would be attached, but it isn't); I can do this far enough so I am 100% sure the mouse isn't restricted by the edge. Furthermore, when experimenting earlier and running gnome-settings-daemon with the make_xinerama_setup removed I see I can no longer cross the right edge; so, the code that make_xinerama_setup calls is definitely doing some xrandr magic with a non present second monitor that shouldn't be happening.

Though, I suppose make_xinerama_setup is a necessity to see anything at all; who knows, it might be drawing gdm to the second screen, which is why I see the black screen with just a cursor that I am currently getting, though, that wouldn't explain why the cursor is on the first screen by default...

Anyhow, I hope you have enough debugging info (above stack trace, failing patch, xrandr output) to proceed with looking into this issue.

Thank you very much in advance; this is one of possibly multiple hoops that made me unable to use Gnome since 3.6 or so, it would be very nice to be able to run Gnome again... :)

Created attachment 249334 [details]
g-s-d.bt.txt

Since GNOME Bugzilla tries to outsmart me with its trace box; I've attached the backtrace as well, that way, you can inspect the parameters and other details gdb gives that may be missing in the way GNOME Bugzilla displays it to you. Maybe it displays better for you, in which case you can ignore this attachment...

(In reply to comment #6)
> Created an attachment (id=249334) [details]
> g-s-d.bt.txt
> 
> Since GNOME Bugzilla tries to outsmart me with its trace box; I've attached the
> backtrace as well, that way, you can inspect the parameters and other details
> gdb gives that may be missing in the way GNOME Bugzilla displays it to you.
> Maybe it displays better for you, in which case you can ignore this
> attachment...

The whole output is here, you clicked on the [+] not on the link :)
https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=232252

Created attachment 249363 [details] [review]
xrandr: Simplify layout of adjacent screens

Rather than going through the loop a number of times,
add the outputs to a GPtrArray directly, and sort it.

I have no idea how we can get to passing "0x1" to gnome_rr_output_info_get_geometry() but that would mean oa = 0x1 thus a = 0x1. But the backtrace shows a=0x7c97f0 when compare_output_positions() is called.

https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xrandr/gsd-xrandr-manager.c?h=gnome-3-8&id=GNOME_SETTINGS_DAEMON_3_8_3#n1051

The above patch reworks and simplifies this section of the code, hopefully it fixes the bug, though I have no idea how that could happen (short of memory corruption).

The overlapping (!) outputs shouldn't be a problem, though the code is probably not made to handle it. Let me know of any problems with the attached patch. If the crash happens still, select the frame with compare_output_positions(), eg:
frame 1
And print the values for "*a", "*b", "*oa", and "*ob" with:
print *a
etc.

Comment on attachment 249334 [details]
g-s-d.bt.txt

(In reply to comment #7)

> The whole output is here, you clicked on the [+] not on the link :)

Yes, noticed that the moment after I attached that; we don't have this at our Bugzilla, I'm not used to it. :D

(In reply to comment #8)
> Created an attachment (id=249363) [details] [review]
> xrandr: Simplify layout of adjacent screens
> 
> Rather than going through the loop a number of times,
> add the outputs to a GPtrArray directly, and sort it.

Cool, thank you for rewriting this bit of code, I'll try it soon.

(In reply to comment #9)
> The above patch reworks and simplifies this section of the code, hopefully it
> fixes the bug, though I have no idea how that could happen (short of memory
> corruption).

Not sure if memory corruption always happens in the same place; but well, I could run it through valgrind if this might be the case to figure out where this might come from.

> The overlapping (!) outputs shouldn't be a problem, though the code is probably
> not made to handle it. Let me know of any problems with the attached patch. If
> the crash happens still, select the frame with compare_output_positions(), eg:
> frame 1
> And print the values for "*a", "*b", "*oa", and "*ob" with:
> print *a
> etc.

Okay, I will ensure to dereference some stuff; thank you in advance.

Result from the patch is that the assertion failure is gone; but, I still get a black screen. There are still three warnings in the below output; do you think any of them might cause a black screen? Also, I can still move my mouse past the right edge of the screen; this isn't normal, so I assume something is still going wrong.

 # DISPLAY=":0" gdb /usr/libexec/gnome-settings-daemon
GNU gdb (Gentoo 7.6 p1) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/libexec/gnome-settings-daemon...Reading symbols from /usr/lib64/debug/usr/libexec/gnome-settings-daemon.debug...done.
done.
(gdb) run
Starting program: /usr/libexec/gnome-settings-daemon
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff7bde700 (LWP 31240)]
[New Thread 0x7ffff73dd700 (LWP 31241)]
[New Thread 0x7ffff67b3700 (LWP 31242)]
[New Thread 0x7ffff5522700 (LWP 31243)]

** (gnome-settings-daemon:31231): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

(gnome-settings-daemon:31231): Gvc-WARNING **: Failed to connect context: OK

** (process:31245): WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
[Thread 0x7ffff5522700 (LWP 31243) exited]
[Thread 0x7ffff7bde700 (LWP 31240) exited]

Comment on attachment 249363 [details] [review]
xrandr: Simplify layout of adjacent screens

Pushed to gnome-3-8 and master.

Attachment 249363 [details] pushed as baa022d - xrandr: Simplify layout of adjacent screens

The other bugs are due to gnome-session and PulseAudio not being present in the session.

I have no idea why the screen ends up black. Is gnome-shell running? Is the mouse cursor visible?

(In reply to comment #13)
> The other bugs are due to gnome-session and PulseAudio not being present in the
> session.

PulseAudio probably doesn't matter here; I see an error for that, I'll file a bug about that to get that separately resolved as well.

As for gnome-session, that is running; is it not being present fatal or not?

> I have no idea why the screen ends up black. Is gnome-shell running? Is the
> mouse cursor visible?

Yes, gnome-shell is running and the mouse cursor is visible.

(In reply to comment #14)
> (In reply to comment #13)
> > The other bugs are due to gnome-session and PulseAudio not being present in the
> > session.
> 
> PulseAudio probably doesn't matter here; I see an error for that, I'll file a
> bug about that to get that separately resolved as well.
> 
> As for gnome-session, that is running; is it not being present fatal or not?

No, but I would expect warnings and some things not to work. gnome-settings-daemon is supposed to be run under a gnome-session.

> > I have no idea why the screen ends up black. Is gnome-shell running? Is the
> > mouse cursor visible?
> 
> Yes, gnome-shell is running and the mouse cursor is visible.

So just the cursor is visible, and none of the shell bits are? Can you try taking a screenshot (with the PrintScreen key by default) so we can check whether some parts of the shell aren't getting rendered for some reason? Does running a terminal make it show up? What's the output of xrandr -q after that?

Heh, maybe a reboot was needed after last testing efforts; I am on Gnome 3.8 now.

As for that second monitor; `xrandr --output DVI-I-1 --off` helps, fixed!