Created attachment 135370 [details] Xquartz stack trace I'm using Xquartz to connect via XDM to a FreeBSD 10.3 machine with CDE 2.2.4 running. It happens quite regularly that Xquartz aborts with the error: __glXExtensionInit: AddExtensions failed. (see also the attached stack trace) I tried to track down the issue with my limited knowledge of Xquartz and Xserver code. So, please be forgiving if my conclusions are totally wrong. This is the result of my analysis: 1. When Xquartz receives an exception it resets the sever -> cleaning everything up and then starting it up again. When starting up, however, it initializes GLX extension (GlxExtensionInit) more than once. This results in exceeding the maximum number of extension errors (LAST_ERROR). I couldn't figure out what actually calls GLX extension again and why. I did implement a hack to work-a-round this problem: I'm keeping track of the number of invocations of GlxExtensionInit and then check at the beginning of GlxExtensionInit whether the number of GlxExtensionInit invocations exceeds the number of serverGenerations. If that's the case GlxExtensionInit does nothing. My preliminary tests indicate, this hack cures the symptom. However, it is not a proper treatment.
This is preventing X11 from running at all on my 10.13.3 Macbook Pro.
Created attachment 140988 [details] [review] Patch originally submitted by "Dietmar M. Zettl" <dietmar@Arthur.zettl-home.net>
Downgrading importance, because macports xorg-server works flawlessly. However, a new release really ought to be done.
> However, it is not a proper treatment. I see two of those (not if they're technically possible or even feasible): - don't abort when an attempt is made to add too many extensions (or even better, get rid of that maximum number alltogether). - don't add the same extension twice.
The patch that I attached ensures that the same extensions aren't added twice.
FWIW, the most recent XOrg (incl. the one that can be built against release versions of all the proto headers) has a regression that at least on Mac causes a systematic crash on exit because of an attempt to free a pointer that wasn't allocated: https://bugs.freedesktop.org/show_bug.cgi?id=107555 Crashing on exit is mostly a nuisance but in this case it happens before a lock file is release so the DISPLAY number increases by one on each subsequent launch of the server.
The first hunk looks fine, but: Why did you switch from pScreen->PaintWindow to miPaintWindow? Why did you change the signal handler for SIGABRT?
> When Xquartz receives an exception it resets the sever -> cleaning everything up and then starting it up again. What is the exception that is triggering this?
Can you send the first hunk as a pull request to https://gitlab.freedesktop.org/xorg/xserver ?
To be honest I don't really know why the second hunk is actually there. I made git-format patch and attached the result. The second hunk was never intended. What I actually meant with "... Xquartz receives an exception" was: when XDMCP declares a session dead it resets the Xserver and after a couple of dead XDMCP sessions the server aborted with __glXExtensinInit:AddExtension failed. There was no Xquartz exception. For which branch should I send in the pull request? server-1.18-branch?
master would be best. It could then be cherry-picked back to the 1.20 branch. I don't think there are any plans for releasing 1.18 or 1.19 again.
I can't apply the patch to master because there is no QuartzExtensionInit function anymore in quartz.c in the master branch. However, I compiled and tested master on my Mac running MacOS 10.14 (Mojave) and the problem doesn't occur anymore. There are other problems though with the master branch - mainly crashes due to freeing a pointer which was not allocated. I therefore reverted back to 1.18-branch.
You should be able to use git blame to figure out why QuartzExtensionInit() was removed and from there decide whether your patch needs refactoring or can be abandoned. As to the bad free crash: if that's the one on exit freeing (IIRC) views then you can just outcomment the loop that does the freeing until upstream decides how they want to address that bug exactly. Not freeing this memory explicitly should be perfectly safe as a local workaround.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/797.
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.