`xrandr --output default --mode <any mode>` causes XQuartz to hang forever.
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1440 x 878, maximum 2880 x 1800
default connected 1440x878+0+0 0mm x 0mm
1440x900 60.00 2.00
I am running OSX El Capitan on a "MacBook Pro (Retina, 15-inch, Early 2013)"
Is there anything else I can provide to help debug this issue?
Please take a spindump focused on X11.bin when you are experiencing this hang. The following command will take about 20 seconds and then tell you the path to the spindump
$ sudo spindump X11.bin
Created attachment 119189 [details]
spindump of X11.bin
I started spindump on X11.bin then immediately executed `xrandr --output default --mode 2880x1800`
For future reference, it's much more ideal to take the spin dump *after* you are spinning because then you will not have noise from the running process and it is more obvious what is stuck.
As for what I see in that spindump, the only thing that looks stuck is inside of NSRunAlertPanel().
Do you not see the alert panel that is asking you for confirmation?
Actually, I'm seeing this as well on OS X 10.11. It looks like an OS X regression. Please file a radar at http://bugreport.apple.com and report back the radar number in this tracker. Thanks.
Also, when filing the radar with Apple, please include an updated spindump, taken *after* it has locked up.
Created attachment 119212 [details]
spindump after hang
Sorry about that -- new to the spindump tool.
Attached is a spindump taken after the hang (this is copy of what I sent in the radar).
The radar number is 23271715
I suspect the usage in XQuartz of doing that off of the main thread might be unsupported, but it still represents a binary compatibility regression, so I'll followup on that radar internally with the appropriate teams, but I'll also work on getting a change into 2.7.9 to better work around this issue.
So actually, the issue is just that the dialog box for some reason isn't visible, but you can actually still hit enter to accept the change. It looks like it is indeed an OS X regression when calling that API on a background thread, so hopefully it should be easily worked around.
This was fixed in 10.11.4.