I reviewed the tests that are skipped because the dll is missing on Windows and I found 4 tests that are never run on Windows which makes them a bit pointless:
* d3dcompiler_46 I can install version 43 and 47 from dxwebsetup.exe without trouble. But d3dcompiler_46.dll? No idea.
* d3drm Is this a deprecated Direct 3D 8 dll? dxwebsetup.exe does not install it.
* msvcr70 As far as I know this dll is part of the Visual Studio 7.0 runtime. But that runtime is nowhere to be found.
* msvcrtd The test look like they succeed on test.winehq.org but in fact all they do is skip the tests:
debug.c:45: Tests skipped: LoadLibraryA failed to load msvcrtd.dll with GLE=126 (where 126 == ERROR_MOD_NOT_FOUND)
That's the debug version of the Visual C++ C library. As such it's not shipped by the runtime redistributables. Also, which C runtime does it correspond to? (iirc it was already there in the 90s)
Note: I'd rather not download these dlls from the many 'not.trojan.horse.dlls.trust.me.com' websites.
VM updates:
* debiant
The gst-plugins-base1.0-dev maintainer intentionally removed multi-arch support in version 1.20.3-2. As a result GStreamer support went missing in 32-bit builds when Wine's detection code was tweaked recently, which in turn caused a lot of new failures (bug 53977).
So I hacked multi-arch support back in and the 32-bit tests are back to normal.
Another point is that updating the X11 / Mesa packages causes the X server to crash during the Direct 3D tests. So for now that VM is frozen in time. That's all worrying for the future Debian 12.
* w11pro64
I added a bunch of Visual Studio C runtime dlls, including msvcr71 which I got through the .Net 1.1 framework. I also added a number of Direct 3D dlls that don't ship with Windows by default.
* w1064v1709
It seems this snapshot was not entirely idle so I retook it after Windows Update finished installing the already downloaded updates (see bug 54158). This does not seem to have made much of a difference :-( (particularly for bug 53227)
* w1064v1909
Windows Defender was not disabled and was intefering with the tests from time to time. That's because 1909 is the first Windows version where Defender cannot be disabled and where I have to exclude the WineTest folder instead. This is fixed now.
* w1064v2004
This snapshot also had some trouble with Windows Update not being idle so I retook it. This does not seem to have made much of a difference either :-(
On 12/22/22 01:57, Francois Gouget wrote:
Another point is that updating the X11 / Mesa packages causes the X server to crash during the Direct 3D tests. So for now that VM is frozen in time. That's all worrying for the future Debian 12.
I don't know if it's related but I recently had to forcefully set GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a d3d12 driver (!!).
Cheers,
Am 22.12.22 um 02:19 schrieb Rémi Bernon:
On 12/22/22 01:57, Francois Gouget wrote:
Another point is that updating the X11 / Mesa packages causes the X server to crash during the Direct 3D tests. So for now that VM is frozen in time. That's all worrying for the future Debian 12.
I don't know if it's related but I recently had to forcefully set GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a d3d12 driver (!!).
Cheers,
Hello, that could probably be https://bugs.debian.org/1025312 , which should already be fixed in unstable, but not yet transitioned to testing.
Kind regards, Bernhard
On Thu, 22 Dec 2022, Rémi Bernon wrote:
On 12/22/22 01:57, Francois Gouget wrote:
Another point is that updating the X11 / Mesa packages causes the X server to crash during the Direct 3D tests. So for now that VM is frozen in time. That's all worrying for the future Debian 12.
I don't know if it's related but I recently had to forcefully set GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a d3d12 driver (!!).
Unfortunately, this did not help with Debian Testing :-(
... 0470:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 14.0.4, 256 bits)"). 0470:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown).
That said Debian Testing broke the libllvm15 package because it requires exactly the same version for the 32- and 64-bit packages (which is reasonable), but they rebuilt just the 32-bit package resulting in a version mismatch (15.0.6-3+b1 vs. 15.0.6-3). In turn that blocks a bunch of packages from upgrading but I'm not sure it would be any better if they did get upgraded.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027026
Am 05.01.23 um 15:33 schrieb Francois Gouget:
On Thu, 22 Dec 2022, Rémi Bernon wrote:
On 12/22/22 01:57, Francois Gouget wrote:
Another point is that updating the X11 / Mesa packages causes the X server to crash during the Direct 3D tests. So for now that VM is frozen in time. That's all worrying for the future Debian 12.I don't know if it's related but I recently had to forcefully set GALLIUM_DRIVER=llvmpipe environment variable when running stuff on Xephyr or over ssh X11 forwarding. Otherwise Mesa was crashing trying to instantiate a d3d12 driver (!!).
Unfortunately, this did not help with Debian Testing :-(
... 0470:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 14.0.4, 256 bits)"). 0470:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown).
That said Debian Testing broke the libllvm15 package because it requires exactly the same version for the 32- and 64-bit packages (which is reasonable), but they rebuilt just the 32-bit package resulting in a version mismatch (15.0.6-3+b1 vs. 15.0.6-3). In turn that blocks a bunch of packages from upgrading but I'm not sure it would be any better if they did get upgraded.
If I see it right, then there should be already 1:15.0.6-4+b1 in testing in amd64 and i386, so it should be co-installable again? Does the X server still crash?
https://packages.debian.org/bookworm/libllvm15 https://snapshot.debian.org/binary/libllvm15/
On Fri, 6 Jan 2023, Bernhard Übelacker wrote: [...]
If I see it right, then there should be already 1:15.0.6-4+b1 in testing in amd64 and i386, so it should be co-installable again? Does the X server still crash?
It does. I also upgraded to unstable and it still crashed :-(
[...] 0454:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 15.0.6, 256 bits)"). 0454:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown).
Am 09.01.23 um 11:32 schrieb Francois Gouget:
On Fri, 6 Jan 2023, Bernhard Übelacker wrote:
Does the X server still crash?
It does. I also upgraded to unstable and it still crashed :-(
[...] 0454:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 15.0.6, 256 bits)"). 0454:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work. X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown).
The Debian bug given seems not directly connected to a crashing X server, is there another report known?
I tried to run a Xephyr server and run the tests of 8.0rc3 inside of it, on top of a current Debian testing.
Could you share more details if Xephyr is started with some parameters, does it give a backtrace or core, and do you have a window manager running inside Xephyr?
And does it happen on a specific wine test?
I am currently running the test suite with "make test -k", but received no crash, but am currently just in dlls/k* tests.
Kind regards, Bernhard
On Tue, 10 Jan 2023, Bernhard Übelacker wrote: [...]
I tried to run a Xephyr server and run the tests of 8.0rc3 inside of it, on top of a current Debian testing.
Could you share more details if Xephyr is started with some parameters, does it give a backtrace or core, and do you have a window manager running inside Xephyr?
The TestBot does not use Xephyr. It uses a regular X server with the QXL driver.
ii xserver-common 2:21.1.6-1 all common files used by various X servers ii xserver-xorg 1:7.7+23 amd64 X.Org X server ii xserver-xorg-core 2:21.1.6-1 amd64 Xorg X server - core server ii xserver-xorg-video-qxl 0.1.5+git20200331-3 amd64 X.Org X server -- QXL display driver
It also runs the fvwm window manager as described on the page below: https://wiki.winehq.org/Wine_TestBot_VMs#Unix_configuration
ii fvwm 1:2.7.0-1 amd64 F(?) Virtual Window Manager
Normally the tests run in a multi-monitor configuration but the crash also happens with a single monitor.
There is a backtrace in /var/log/Xorg.0.log:
[ 71.406] (EE) [ 71.406] (EE) Backtrace: [ 71.406] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5648efd6bcc9] [ 71.406] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f807185af90] [ 71.406] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) [0x7f80718a9ccc] [ 71.406] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7f807185aef2] [ 71.407] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7f8071845472] [ 71.407] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 71.407] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f8071845395] [ 71.407] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7f8071853df2] [ 71.407] (EE) 7: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0xc33) [0x5648efd241e3] [ 71.407] (EE) 8: /usr/lib/xorg/Xorg (DRI2Authenticate+0xad) [0x5648efd2647d] [ 71.407] (EE) 9: /usr/lib/xorg/Xorg (DRI2GetParam+0x6cb) [0x5648efd271fb] [ 71.407] (EE) 10: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x5648efbf8734] [ 71.407] (EE) 11: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x5648efbfc6cc] [ 71.407] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f807184618a] [ 71.407] (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f8071846245] [ 71.407] (EE) 14: /usr/lib/xorg/Xorg (_start+0x21) [0x5648efbe5b71] [ 71.407] (EE) [ 71.407] (EE) Fatal server error: [ 71.407] (EE) Caught signal 6 (Aborted). Server aborting
And does it happen on a specific wine test?
It's enough to run the amstream:amstream test.
On Thu, 12 Jan 2023, Francois Gouget wrote: [...]
And does it happen on a specific wine test?
It's enough to run the amstream:amstream test.
More precisely it crashes in the gst_init_check() call! That is, the test works till line 464:
464 check_interface(filter, &IID_IMediaSeeking, FALSE);
And the crash happens in dlls/winegstreamer/wg_parser.c in init_gstreamer_once():
1673 if (!gst_init_check(&argc, &argv, &err))
I guess the good news is that I can crash the X server with:
gst-play-1.0 no-such-file.avi
And it turns out to be caused by the Xv support so a workaround is to uninstall the gstreamer1.0-vaapi package. Given that it's pretty basic functionality that's broken (though maybe it's a bad interaction with QXL) there's hope that it will be fixed in time.
Am 12.01.23 um 14:34 schrieb Francois Gouget:
On Thu, 12 Jan 2023, Francois Gouget wrote: [...]
And does it happen on a specific wine test?
It's enough to run the amstream:amstream test.
More precisely it crashes in the gst_init_check() call! That is, the test works till line 464:
464 check_interface(filter, &IID_IMediaSeeking, FALSE);
And the crash happens in dlls/winegstreamer/wg_parser.c in init_gstreamer_once():
1673 if (!gst_init_check(&argc, &argv, &err))
I guess the good news is that I can crash the X server with:
gst-play-1.0 no-such-file.avi
And it turns out to be caused by the Xv support so a workaround is to uninstall the gstreamer1.0-vaapi package. Given that it's pretty basic functionality that's broken (though maybe it's a bad interaction with QXL) there's hope that it will be fixed in time.
Hello Francois, sorry for the delay. I have tried to reproduce and found the X-server hitting an assert.
Unfortunately I found in the upstream Xserver tracker no exact matching report and no fix.
Therefore I have opened following issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1534
There is also a patch that would avoid hitting the assert, instead return DRI2Authenticate with FALSE. Maybe having that applied to a locally built xserver-xorg-core package could be another workaround instead of uninstalling gstreamer1.0-vaapi.
Unfortunately the QXL driver package was removed from Debian testing most part of the last year, maybe therefore got less tested: https://tracker.debian.org/pkg/xserver-xorg-video-qxl
Kind regards, Bernhard
Am 19.03.23 um 13:29 schrieb Bernhard Übelacker:
Am 12.01.23 um 14:34 schrieb Francois Gouget:
On Thu, 12 Jan 2023, Francois Gouget wrote: [...]
And does it happen on a specific wine test?
It's enough to run the amstream:amstream test.
More precisely it crashes in the gst_init_check() call! That is, the test works till line 464:
464 check_interface(filter, &IID_IMediaSeeking, FALSE);
And the crash happens in dlls/winegstreamer/wg_parser.c in init_gstreamer_once():
1673 if (!gst_init_check(&argc, &argv, &err))
I guess the good news is that I can crash the X server with:
gst-play-1.0 no-such-file.avi
And it turns out to be caused by the Xv support so a workaround is to uninstall the gstreamer1.0-vaapi package. Given that it's pretty basic functionality that's broken (though maybe it's a bad interaction with QXL) there's hope that it will be fixed in time.
Hello Francois, sorry for the delay. I have tried to reproduce and found the X-server hitting an assert.
Unfortunately I found in the upstream Xserver tracker no exact matching report and no fix.
Therefore I have opened following issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1534
There is also a patch that would avoid hitting the assert, instead return DRI2Authenticate with FALSE. Maybe having that applied to a locally built xserver-xorg-core package could be another workaround instead of uninstalling gstreamer1.0-vaapi.
Unfortunately the QXL driver package was removed from Debian testing most part of the last year, maybe therefore got less tested: https://tracker.debian.org/pkg/xserver-xorg-video-qxl
Kind regards, Bernhard
Hello Francois, I wondered how this worked in Bullseye/stable and reported another issue to libva. https://github.com/intel/libva/issues/700
Let's see how the reactions are.
Kind regards, Bernhard
- d3dcompiler_46 I can install version 43 and 47 from dxwebsetup.exe without trouble. But d3dcompiler_46.dll? No idea.
According to winetricks:
win32 http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A52509... 2630bae9681db6a9f6722366f47d055c.cab fil47ed91e900f4b9d9659b66a211b57c39 -> d3dcompiler_46.dll
win64 http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A52509... 61d57a7a82309cd161a854a6f4619e52.cab fil8c20206095817436f8df4a711faee5b7 -> d3dcompiler_46.dll
- d3drm Is this a deprecated Direct 3D 8 dll? dxwebsetup.exe does not install it.
Yes, but I thought it's shipped with Windows XP. At least on my VM, it is. winetricks gets it from https://files.holarse-linuxgaming.de/mirrors/microsoft/ directx_feb2010_redist.exe (dxnt.cab), but it's not installed on Win7... Is extracting it from the directx redist an option for the VMs?
- msvcr70 As far as I know this dll is part of the Visual Studio 7.0 runtime. But that runtime is nowhere to be found.
I managed to source one: https://web.archive.org/web/20060509134332/http:// download.microsoft.com/download/4/1/a/41a70f33-ee71-417c-b830-4d3bd0acac13/ VS7.0sp1-KB837234-X86.exe Needs manual extraction though, and the files have weird names. Apart from that, it should work.
Hope that is of use.
Regards, Fabian Maurer
On Thu, 22 Dec 2022, Fabian Maurer wrote:
- d3dcompiler_46 I can install version 43 and 47 from dxwebsetup.exe without trouble. But d3dcompiler_46.dll? No idea.
According to winetricks:
[...]
Hope that is of use.
Thanks. It would be nice to have a more standard / official way of installing these but such a way probably does not exist anymore.
-
Bernhard Übelacker -
Fabian Maurer -
Francois Gouget -
Rémi Bernon