Created attachment 125966 [details] Winedebug log Using mesa-git crashes wine, works fine with with normal mesa. The program crashes somewhere in libxshmfence, most likely related to DRI3. Issue not present if "LIBGL_ALWAYS_SOFTWARE" or "LIBGL_DRI3_DISABLE" is set. Attached a crash log from winedbg, if you need more information I'll provide it. Systeminfo: -Arch 64bit -Radeon R9 285 using amdgpu and opensource driver -OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel (git-0328b20) -OpenGL version string: 3.0 Mesa 12.1.0-devel (git-0328b20) -mesa-git and mesa-libgl-git (84113.0328b20), libdrm-git (5912.b214b05)
Can you bisect Mesa?
I'd like to, but the older versions fail due to the wrong version of llvm/clang. Is there somewhere a tutorial how to compile both together?
Assuming you can reproduce the problem with Mesa Git + LLVM 3.9/3.8, you can stick to the latter for bisecting. If you run into any clang related issues, you can build Mesa with --disable-opencl for the bisection.
I managed to downgrade mesa to 11.2.2, but the issue persisted. Figured out it can be fixed by downgrading "xf86-video-amdgpu" from git to stable. Now I'm not sure wheter this bug is a mesa issue or from that project. Since I didn't mention it yet, the issue is with (any) wine and N-Ball(http://www.ragdollsoft.com/nball/). It has a demo and crashes right on startup. I'd provide an apitrace, but if it's made with "LIBGL_ALWAYS_SOFTWARE" or "LIBGL_DRI3_DISABLE", then it replays fine. If made it without, the trace is cut of before the crashing part. Also, the bug is non-deterministic. It works most of the time if I edit wine and put a 1 second sleep before "glXSwapBuffers", maybe a racecondition. Is this still the right place for this issue?
Can you bisect xf86-video-amdgpu then? :)
Sorry, I think my local git tree was a few days out of date, what gave me some strange issues, sorry for wasting your time with that. The issue seems to have been already fixed in "1e3218bc5ba2b739261f0c0bacf4eb662d377236", and while this commit seems performance related, at least that fixes the crash for me. Reverting that commit brought back the crash. Though I don't know if this is a genuine fix for the issue I experienced or just a lucky coincidence. After all the downgrade to xf86-video-amdgpu did help, too. Should I still bisect xf86-video-amdgpu to see where thats changes introduced the crash? I guess it's some kind of odd issue with interaction between those two parts.
(In reply to Fabian Maurer from comment #6) > Should I still bisect xf86-video-amdgpu to see where thats changes > introduced the crash? That would be interesting. It definitely shouldn't crash even without that Mesa change.
The commit introducing this issue is "861da1d5c243f51d6c1f76e5b13e5184aa608776" ("Enable DRI3 by default when building for Xorg >= 1.18.3"). So this doesn't really help, seems like DRI3 was faulty to begin with. An idea how to investigate this issue further?
A proper gdb backtrace of a crash might be helpful.
Created attachment 126105 [details] gdb backtrace Backtrace from winebdg in gdb mode. Normal gdb doesn't like wine and always reports broken stackframes with no symbols, but this should be the same output anyways.
Is this still happening with current Mesa?
No, doesn't seem to happen anymore.
(In reply to Fabian Maurer from comment #12) > No, doesn't seem to happen anymore. Glad to hear that, thanks for the follow-up!
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.