[Xquartz-dev] XQuartz 2.7.10_beta1

[Jeremy Huddleston Sequoia]

I have just released XQuartz 2.7.10_beta1. The only changes from 2.7.9 are updates to mesa 11.2.1 and xorg-server 1.18.3. Note that as with the 2.7.9 betas, this version is built with ASan which will help with error reporting but may have a negative impact on performance.

https://www.xquartz.org/releases/XQuartz-2.7.10_beta1.html

Due to an issue with akami.bintray.com not satisfying ATS requirements, you may have trouble automatically updating from 2.7.9 to 2.7.10_beta1. I've already reported the issue to bintray. If you have issues downloading the update automatically, please do a manual install.

Thanks,
Jeremy

[Tom Lane]

Post by Jeremy Huddleston Sequoia
I have just released XQuartz 2.7.10_beta1. The only changes from 2.7.9 are updates to mesa 11.2.1 and xorg-server 1.18.3. Note that as with the 2.7.9 betas, this version is built with ASan which will help with error reporting but may have a negative impact on performance.

I tried 2.7.10_beta1 for a couple of days, and gave up because of this
odd behavior:

When attempting "ulimit -c unlimited" in bash running in an xterm window
under beta1, I get a "permission denied" type of error (don't have the
exact wording handy). It appears that something in beta1 is forcing the
hard limit for core size down to zero for subprocesses of an xterm. This
doesn't happen in 2.7.9, nor when running bash under Terminal. Possibly
it's a side effect of ASan, but if so, it's one that I've not seen in
previous versions, and it makes XQuartz next to unusable for my daily
development work.

Another thing I ran into is that when keeping an X11-aware build of Emacs
open within my XQuartz sessions, I find it disappears from the screen
after allowing my laptop to sleep and wake from sleep. The emacs process
is still there according to ps, and its window is still listed in
XQuartz's Window menu, but I can't see it, nor pull it up using the Window
menu item. I've now found that I can reproduce this in 2.7.9 as released,
though I'm sure it was not happening last time I tried to do this a few
months ago. (I might still have been on Yosemite at that point, not
sure. Normally I do this with a remote emacs, which hasn't shown any
sign of trouble --- it's only emacs running locally on my laptop that
is problematic.) Any ideas about debugging that, or a workaround?

regards, tom lane

[Tom Lane]

Post by Tom Lane
Another thing I ran into is that when keeping an X11-aware build of Emacs
open within my XQuartz sessions, I find it disappears from the screen
after allowing my laptop to sleep and wake from sleep.

After some further experimentation, I've realized that what is happening
is that the window is being redisplayed completely off-screen. In
general, it seems like sleep and then wake results in all my existing
windows being repositioned -- although only the first time; that is,
once repositioned in a sleep/wake cycle, a window is not further affected
by additional sleep/wake cycles. The extent of repositioning seems to
vary depending on how the window was positioned internally. The worst
case I'm seeing, with the emacs window getting repositioned totally off
screen, happens with a window whose initial geometry spec is "-0+0",
ie pin to the upper right corner. I don't have an explanation for why
this happens with local X11 clients and not remote ones with similar
geometry specs.

Known problem? Should I file a ticket?

regards, tom lane

[Ken Preslan]

Post by Tom Lane

Post by Tom Lane
Another thing I ran into is that when keeping an X11-aware build of Emacs
open within my XQuartz sessions, I find it disappears from the screen
after allowing my laptop to sleep and wake from sleep.

After some further experimentation, I've realized that what is happening
is that the window is being redisplayed completely off-screen. In
general, it seems like sleep and then wake results in all my existing
windows being repositioned -- although only the first time; that is,
once repositioned in a sleep/wake cycle, a window is not further affected
by additional sleep/wake cycles. The extent of repositioning seems to
vary depending on how the window was positioned internally. The worst
case I'm seeing, with the emacs window getting repositioned totally off
screen, happens with a window whose initial geometry spec is "-0+0",
ie pin to the upper right corner. I don't have an explanation for why
this happens with local X11 clients and not remote ones with similar
geometry specs.

I've seen this happen ever since switching to El Capitan. I believe Dave
Borman started a thread on the topic a few months ago.