22 Dec
2022
22 Dec
'22
12:57 a.m.
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 :-(
--
Francois Gouget <fgouget(a)codeweavers.com>
22 Dec
22 Dec
1:19 a.m.
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,
--
Rémi Bernon <rbernon(a)codeweavers.com>
5:20 p.m.
Am 22.12.22 um 02:19 schrieb Rémi Bernon:
On 12/22/22 01:57, Francois Gouget wrote:
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
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,
6:05 p.m.
* 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-8A5250…
2630bae9681db6a9f6722366f47d055c.cab
fil47ed91e900f4b9d9659b66a211b57c39 -> d3dcompiler_46.dll
win64
http://download.microsoft.com/download/F/1/3/F1300C9C-A120-4341-90DF-8A5250…
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
28 Dec
28 Dec
6:53 p.m.
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.
--
Francois Gouget <fgouget(a)codeweavers.com>
5 Jan
5 Jan
2:33 p.m.
On Thu, 22 Dec 2022, Rémi Bernon wrote:
On 12/22/22 01:57, Francois Gouget wrote:
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
--
Francois Gouget <fgouget(a)codeweavers.com>
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 (!!).
6 Jan
6 Jan
10:46 p.m.
Am 05.01.23 um 15:33 schrieb Francois Gouget:
On Thu, 22 Dec 2022, Rémi Bernon 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?
https://packages.debian.org/bookworm/libllvm15
https://snapshot.debian.org/binary/libllvm15/
On 12/22/22 01:57, Francois Gouget wrote:
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
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 (!!).
9 Jan
9 Jan
10:32 a.m.
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).
--
Francois Gouget <fgouget(a)codeweavers.com>
10 Jan
10 Jan
10:52 a.m.
Am 09.01.23 um 11:32 schrieb Francois Gouget:
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 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).
12 Jan
12 Jan
9:17 a.m.
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.
--
Francois Gouget <fgouget(a)codeweavers.com>
1:34 p.m.
On Thu, 12 Jan 2023, Francois Gouget wrote:
[...]
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.
--
Francois Gouget <fgouget(a)codeweavers.com>
And does it
happen on a specific wine test?
It's enough to run the amstream:amstream test.
19 Mar
19 Mar
12:29 p.m.
Am 12.01.23 um 14:34 schrieb Francois Gouget:
On Thu, 12 Jan 2023, Francois Gouget wrote:
[...]
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
And does
it happen on a specific wine test?
It's enough to run the amstream:amstream test.
2:23 p.m.
Am 19.03.23 um 13:29 schrieb Bernhard Übelacker:
Am 12.01.23 um 14:34 schrieb Francois Gouget:
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
On Thu, 12 Jan 2023, Francois Gouget wrote:
[...]
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
And does
it happen on a specific wine test?
It's enough to run the amstream:amstream test.
427
days inactive
514
days old
12 comments
4 participants
participants (4)
-
Bernhard Übelacker -
Fabian Maurer -
Francois Gouget -
Rémi Bernon