Created attachment 138347 [details] xorg log A crash is encountered while running wine's dxgi tests: [ 65.515] (EE) Segmentation fault at address 0x10 ... [ 65.515] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4e) [0x55b867cec6ce] [ 65.515] (EE) 1: /usr/lib/xorg/Xorg (0x55b867b3a000+0x1b6a69) [0x55b867cf0a69] [ 65.515] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7fe15a598000+0x354b0) [0x7fe15a5cd4b0] [ 65.515] (EE) 3: /opt/xorg/lib/xorg/modules/drivers/amdgpu_drv.so (0x7fe1562eb000+0xdb9b) [0x7fe1562f8b9b] [ 65.515] (EE) 4: /usr/lib/xorg/Xorg (0x55b867b3a000+0xd4bc9) [0x55b867c0ebc9] [ 65.515] (EE) 5: /usr/lib/xorg/Xorg (BlockHandler+0x4a) [0x55b867b927ca] amdgpu_drv.so+0xdb9b is src/amdgpu_kms.c:990 It seems drmmode_crtc->scanout_damage is NULL when amdgpu_scanout_flip() is called.
Created attachment 138348 [details] [review] workaround patch This patch workarounds the issue and wine's tests run to completion.
Do you have any pointers to information about how to run this test?
Created attachment 138644 [details] wine's dxgi test exe You need to build wine from source, I'm using the 64bit version, which should be something like: > git clone git://source.winehq.org/git/wine.git && cd wine > ./configure --prefix=/somewhere --enable-win64 > # (install dependencies and rerun configure as needed) > make # -jN and then run the test: > make -C dlls/dxgi/tests/ testclean test Alternatively install recent official binary packages and just run the attached .exe under wine (it's compiled with wine's "make crosstest", which is intended to run wine's tests under Windows).
Thanks, but unfortunately, the attached executable crashes for me. Does it depend on anything in particular being installed in the Wine prefix, or any specific Wine configuration? Any chance you can do the following: Before reproducing the problem, attach gdb to Xorg and set a breakpoint in drmmode_crtc_scanout_free. Then reproduce the problem. When the breakpoint triggers, run bt full and attach the output here.
Created attachment 138672 [details] gdb log Strange, it reproduces for me on a fresh wine prefix (which means everything on defaults) like this: > WINEPREFIX=/tmp/wpx/ ~/src/wine/wine64/wine64 /tmp/dxgi_crosstest.exe Maybe missing GL on your setup? > ~/src/wine/wine64/wine64 --version > wine-3.4-142-g5946973 Anyway gdb backtrace attached.
Does https://patchwork.freedesktop.org/patch/217412/ prevent this, by any chance?
No it doesn't (both original patch and the one that was pushed). Anything wrong with just checking if drmmode_crtc->scanout_damage is not NULL? amdgpu_scanout_update() already does that, for example.
(In reply to Grazvydas Ignotas from comment #7) > Anything wrong with just checking if drmmode_crtc->scanout_damage is not > NULL? That would just be a band-aid. drmmode_crtc->scanout_damage is supposed to be always there when drmmode_crtc->tear_free == TRUE, I'd like to get to the bottom of how that's violated. When the drmmode_crtc_scanout_free breakpoint triggers, can you also print *drmmode_crtc?
Created attachment 138960 [details] *drmmode_crtc printout
Created attachment 139015 [details] [review] Don't call scanout_flip/update with a legacy RandR scanout buffer Does this patch fix the crash?
Created attachment 139016 [details] [review] Simplify drmmode_handle_transform Can you test this patch as well? It might avoid the crash as well, by making TearFree work in this case.
Both patches (in isolation) solve the issue, thanks.
Thanks for the report and testing. Fixed in Git: commit 463477661c88cab3a87746499e5838c5b9f9a13b Author: Michel Dänzer <michel.daenzer@amd.com> Date: Mon Apr 23 18:44:06 2018 +0200 Don't call scanout_flip/update with a legacy RandR scanout buffer
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.