`xrandr --output default --mode <any mode>` causes XQuartz to hang forever. bash-3.2$ xrandr 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 2880x1800 60.00 1440x900 60.00 2.00 2560x1600 60.00 2048x1280 60.00 1024x768 60.00 800x600 60.00 640x480 60.00 1680x1050 60.00 1280x800 60.00 1440x878 1.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? Thanks
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` Thanks
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 Thanks!
Thanks. 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.