The mscoree one is a genuine UAF bug, other are more arguably false positive but GCC doesn't like freed pointer value to be used in any way.
--
v2: server: Avoid using pointer value after realloc.
d3drm: Avoid using pointer value after free.
dsound: Avoid using pointer value after free.
notepad: Avoid using pointer value after free.
msi: Avoid using pointer value after free.
user32/tests: Workaround use after free warnings.
oleaut32/tests: Workaround use …
[View More]after free warnings.
mshtml/tests: Avoid using pointer value after free.
mscoree: Avoid using pointer after free.
https://gitlab.winehq.org/wine/wine/-/merge_requests/180
[View Less]
New hardware
------------
The TestBot is getting two new VM hosts, gpu1 and gpu2.
* Thanks to their i9-12900K processor they have much better
multi-threaded performance: compiling Wine from scratch went from
about 920 seconds on the old boxes to 220 seconds with 16 threads, and
190 seconds with 24 threads [1] (all numbers include the configure
step). That should help with patches that touch Wine headers.
* They also have much better single-thread performance. The first
results …
[View More]indicate that they can run WineTest in Wine in about 20
minutes instead of 36 minutes.
* They should support PCI-passthrough and each has an AMD RX 6600 and an
Nvidia RTX 3050 graphics card. That means it should be possible to
test every patch against these graphics cards (unlike the cw-rx460 and
cw-gtx560 machines which only ran WineTest and were not fully part of
the TestBot).
* They should also be able to run Windows 11 in a VM.
The sad news is that they literally replace cw-rx460 and cw-gtx560 so
those two are no more. So PCI-passthrough is needed to provide continued
tests against real GPUs. The current status:
* gpu1 is in place and part of the TestBot but only runs 'vanilla' VMs.
* gpu2 has now replaced cw-gtx560 but is not set up yet. I will first
use it as a testbed to set up the PCI-passthrough and Windows 11 VMs.
That way I'll be able to reboot gpu2 without impacting the TestBot. I
will also document the result on the WineTestBot VMs page [2] in case
anyone wants to do the same at home.
VM updates
----------
* I updated debian11 and installed the fonts-arphic-uming package for
the Chinese tests. I suspect the debian11 update caused a lot of new
ddraw[12] failures. (950 failures / crash instead of 1 failure,
qualitatively it makes no difference but it still needs to be
investigated...)
* I did a Windows Update on the w8 and w864 VMs. They are now fully
updated and while going through the check list [2] I found items that
probably were missing (e.g. not disabling defragmentation).
* I changed the w8 CPU from kvm32 to core2duo because Windows would not
boot otherwise; seemingly due to the lack of support for the NX bit. I
suspect that's because the host CPU went from AMD to Intel and QEmu
failed to insulate the guest from that despite the kvm32 virtual CPU
type. w864 was already running with the QEmu CPU set to core2duo so
that should be ok.
VM reshuffling
--------------
I moved the VMs around to take advantage of the new gpu1 box.
* vm3 and vm4 are now dedicated to running w1064* and w10pro64*
respectively (before they had one additional VM each). This should
help reduce the period of time during which the TestBot is less
responsive due to the nightly WineTest runs.
* I moved debian11 and debiant to gpu1 so they benefit from the
faster compilations and faster WineTest runs.
(WineTest is much slower in Wine than on Windows so maximum benefit
there)
* I moved w864 to gpu1. The good thing is that this confirmed the old
VMs work on the new boxes too (see the kvm32 issue above).
* I moved all the other Windows VMs to vm1.
* Next the plan is to move the build VM somewhere and to retire the vm2
host.
There will be one more reshuffling once gpu2 is in place but what
happens then will depend very much on how many test configurations use
the PCI-passthrough, Windows 11, and GitLab.
[1] Note: when building a Wine build server it seems one needs between
350 and 400 MB per compilation thread. For now I have allocated 16
threads to the VMs but, given that they currently still only run one
VM at a time, giving them access to all 24 thread may make more
sense.
There is also the issue of performance vs efficiency cores. But
making sure the VMs only use performance cores would require
CPU-pinning and I don't want to go there unless proven necessary.
[2] https://wiki.winehq.org/Wine_TestBot_VMs#Windows_configuration
--
Francois Gouget <fgouget(a)codeweavers.com>
[View Less]