Skip to content
Permalink
master
Go to file
 
 
Cannot retrieve contributors at this time
268 lines (137 sloc) 9.31 KB
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component cc
2012-04-29 06:23:59 -0700
2015-09-01 21:51:04 -0700
2012-05-16 19:01:10 -0700
closed
usability
Fixed
doh123@…
jeremyhu@…
Blocker
2.7.2
GLX
jonas.maebe@…
doh123@…

Xquartz 2.7.2 rc1 Wine problem with mesa

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@… commented on Apr 29, 2012

  • Status changed from new to assigned
  • Priority changed from Not Set to Blocker
  • Milestone set to 2.7.2

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@… commented on Apr 30, 2012

  • Cc jonas.maebe@… added

doh123@… commented on May 7, 2012

  • Cc doh123@… added

doh123@… commented on May 10, 2012

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@… commented on May 10, 2012

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@… commented on May 15, 2012

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

http://pastebin.com/K94s3ztf


jeremyhu@… commented on May 16, 2012

That is actually a huge difference...


jeremyhu@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

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


jonas.maebe@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

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@… commented on May 16, 2012

  • Status changed from assigned to closed
  • Resolution changed from to fixed

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


jeremyhu@… commented on May 16, 2012

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

You can’t perform that action at this time.