Xquartz 2.7.2 rc1 Wine problem with mesa

[doh123@…]

Running Oblivion (my main test case) in 2.7.2 beta4 works fine. It broke in rc1.

xp_destroy_surface: assertion failed: s != NULL xp_destroy_surface error: 3 X Error of failed request: 0

Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) Serial number of failed request: 1377 Current serial number in output stream: 1377

This was talked about on the dev list. ​http://lists.macosforge.org/pipermail/xquartz-dev/2012-April/003596.html

[jeremyhu@…]

Please do the following:

1) Use my current HEAD and run with LIBGL_DIAGNOSTIC=1 ... this should produce useful logs.

2) Checkout the PR-575 branch and make sure that it actually works. This branch only has the first crash fix and not the one dealing with locking.

Also, please verify that wine is using the right libGL. If it is, then for #1 you should see messages that look like:

Debug          apple_glx_context.c:202  apple_glx_create_context(26009002): ..."

rather than the old ones:

DIAG: ....

[jonas.maebe@…]

Cc Me!

[doh123@…]

Cc Me!

[doh123@…]

I used RC2 so i didn't have to build... (i'm guessing that is ok)

I got the following with LIBGL_DIAGNOSTIC=1

​http://pastebin.com/LMcY9ta5

I retested my stock Mesa 8.0.2 and retested 2.7.2beta4 to make sure they still worked with no crash... and they still work fine.

[jeremyhu@…]

Ok, so the new error is actually different:

Debug         apple_glx_drawable.c:175  destroy_drawable(76261): destroy_drawable: freeing 0x40b03200
pthread_mutex_destroy error: Resource busy
wine: Assertion failed at address 0x000b:0x95c1b9c6 (thread 0009), starting debugger...

Please try my PR-575 branch, see ​http://cgit.freedesktop.org/~jeremyhu/mesa

[doh123@…]

PR-575 branch, not sure anything changed, beside the diag messages being a bit different.

​http://pastebin.com/K94s3ztf

[jeremyhu@…]

That is actually a huge difference...

[jeremyhu@…]

You're not using the right branch... pleae make sure you are using the correct branch. The error messages are formatted like an older version. You should see messages formatted like:

Debug         apple_glx_drawable.c:175  destroy_drawable(76261): destroy_drawable: freeing 0x40b03200

not like:

DIAG: destroy_drawable: freeing 0x4422a000

[jeremyhu@…]

Make sure you do:

git clone git://people.freedesktop.org/~jeremyhu/mesa
cd mesa
git checkout -f PR-575
make darwin INSTALL_DIR=/opt/X11 CC=clang CXX=clang++ EXTRA_CFLAGS="-g3 -gdwarf-2 -O0"
sudo make install INSTALL_DIR=/opt/X11 

And make sure your wine is built to use /opt/X11/lib/libGL. If it's using /opt/local/lib/libGL, you'll need to change the INSTALL_DIR above to clobber MacPorts' mesa.

[doh123@…]

I cannot ever get Mesa to build correctly just doing it manually... your options above fail.

I already have been building Mesa through Macports with a local portfile set up, so I sat one up to point to your mesa git and the right branch, and it claims its getting the right branch... somehow its not. The libGL is set to be /opt/X11 not /opt/local... and Wine is looking in /opt/X11... I can easily drop in a working libGL and prevent the crash in /opt/X11/lib.

if you want to help me on why its not building normally, thats fine too. heres the log trying to build it the way you say. ​http://pastebin.com/rF82KEyp

I have no idea why Macports isn't pulling the right branch.. i have several things I build using Macports all the time with my own local portfiles, but I've never tried pulling anything from a different branch on git before. I tried setting git.branch to PR-575, which didn't give any errors... (if I named it to a branch that doesn't exist it gave errors), and also tried the actual commit, which it act like it pulled fine too. If I set it to your main git head, it pulls and builds fine, but i thought something was fishy with that log.

[jonas.maebe@…]

Replying to doh123@…:

if you want to help me on why its not building normally, thats fine too. heres the log trying to build it the way you say. ​http://pastebin.com/rF82KEyp

I solved that using the following:

a) download ​http://xmlsoft.org/sources/libxml2-2.7.3.tar.gz

b) configure/build/install via

./configure --with-python=/System/Library/Frameworks/Python.framework/Versions/2.6/
make
sudo make install 

(yes, not very clean; I guess you can achieve the same effect with one or other macports package too).

BTW, for building I use this command afterwards (extra arch parameters added at the end of EXTRA_CFLAGS):

make darwin INSTALL_DIR=/opt/X11 CC=clang CXX=clang++ EXTRA_CFLAGS="-g3 -gdwarf-2 -O0 -arch i386 -arch x86_64"

The reason is that Wine is a 32 bit binary, so you need a 32 bit mesa too.

[jonas.maebe@…]

And one more thing: before rebuilding mesa with the extra arch options, make sure to both "make clean" and "rm src/glx/*.o", because make clean doesn't delete everything and otherwise you'll get linking errors about missing 32 bit object code.

[doh123@…]

is there a way I can tell it to find my libxml2 thats already installed via Macports...?

[jonas.maebe@…]

It's probably more a matter of telling it to use your Macports' Python installation (the problem is not libxml2 per se, because that one is also available in a default Mac OS X install, but the Python interface modules for libxml2). I don't know how you can tell configure to use a non-default Python, but I'm sure there is a way. I can't check currently though.

[jeremyhu@…]

Ok, I think this should do it for you:

git clone git://people.freedesktop.org/~jeremyhu/mesa
cd mesa
git checkout -f PR-575
make darwin INSTALL_DIR=/opt/X11 CC=clang CXX=clang++ EXTRA_CFLAGS="-g3 -gdwarf-2 -O0 -arch x86_64 -arch i386" PYTHON2="/opt/local/bin/python2.7"
sudo make install INSTALL_DIR=/opt/X11 

assuming your MacPorts python binary is /opt/local/bin/python2.7 and you have py27-libxml2 installed (sudo port -v install py27-libxml2) ... python2.6 with py26-libxml2 will work as well.

[doh123@…]

ok.. good news, that worked ok to build it!

also good news... it fixes the crash... Oblivion seems to be running fine with this build.

[jeremyhu@…]

Thanks for testing. The changes have been pushed to the 7.11, 8.0, and master branches.

[jeremyhu@…]

It is also now fixed in MacPorts' mesa port. It will land in XQuartz 2.7.2 rc3.