Bug 103662 - Xserv aborts with __glXExtensionInit: AddExtensions failed.
Summary: Xserv aborts with __glXExtensionInit: AddExtensions failed.
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 2.7.11 (xserver-1.18.4)
Hardware: x86 (IA32) Mac OS X (All)
: high major
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
Depends on:
Reported: 2017-11-10 08:37 UTC by Dietmar M. Zettl
Modified: 2019-05-23 18:32 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Xquartz stack trace (62.65 KB, text/plain)
2017-11-10 08:37 UTC, Dietmar M. Zettl
Patch originally submitted by "Dietmar M. Zettl" <dietmar@Arthur.zettl-home.net> (2.14 KB, patch)
2018-08-06 23:26 UTC, John Lindal
Details | Splinter Review

Description Dietmar M. Zettl 2017-11-10 08:37:38 UTC
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.
Comment 1 John Lindal 2018-08-06 23:24:58 UTC
This is preventing X11 from running at all on my 10.13.3 Macbook Pro.
Comment 2 John Lindal 2018-08-06 23:26:50 UTC
Created attachment 140988 [details] [review]
Patch originally submitted by "Dietmar M. Zettl" <dietmar@Arthur.zettl-home.net>
Comment 3 John Lindal 2018-08-07 22:23:02 UTC
Downgrading importance, because macports xorg-server works flawlessly.

However, a new release really ought to be done.
Comment 4 René J.V. Bertin 2018-08-11 19:57:26 UTC
> 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.
Comment 5 John Lindal 2018-08-13 18:22:11 UTC
The patch that I attached ensures that the same extensions aren't added twice.
Comment 6 René J.V. Bertin 2018-08-15 07:43:13 UTC
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:


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.
Comment 7 Jeremy Huddleston Sequoia 2018-09-12 19:03:36 UTC
The first hunk looks fine, but:

    Why did you switch from pScreen->PaintWindow to miPaintWindow?

    Why did you change the signal handler for SIGABRT?
Comment 8 Jeremy Huddleston Sequoia 2018-09-12 19:04:39 UTC
> 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?
Comment 9 Jeremy Huddleston Sequoia 2018-09-12 19:15:33 UTC
Can you send the first hunk as a pull request to https://gitlab.freedesktop.org/xorg/xserver ?
Comment 10 Dietmar M. Zettl 2018-09-13 14:49:36 UTC
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?
Comment 11 Jeremy Huddleston Sequoia 2018-09-27 10:24:08 UTC
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.
Comment 12 Dietmar M. Zettl 2018-10-23 05:37:05 UTC
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.
Comment 13 René J.V. Bertin 2018-10-23 07:36:35 UTC
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.
Comment 14 GitLab Migration User 2019-05-23 18:32:19 UTC
-- 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.