With GitLab and the spinning off of commit messages to wine-gitlab I
think the traffic estimates on the mailing list page need to be
updated... at least for wine-devel: it no longer has 50 messages per
day.
https://www.winehq.org/forums
(unfortunately there is no unit on the little per mailing-list graph)
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Theory is where you know everything but nothing works.
Practice is where everything works but nobody knows why.
Sometimes they go hand in hand: nothing works and nobody knows why.
I have been reviewing the TestBot and GitLab CI test results for the
merged MRs. While doing that I updated the TestBot's known failures list
(https://testbot.winehq.org/FailuresList.pl) in order to drive down the
false positive rate.
Incidentally I also collected the list of test units causing false
positives, so I'll start with that. Specifically, here are the bugs to
fix to help the GitLab CI:
* Bug 53433 - mmdevapi:capture - impacted 18 MRs
* Bug 54064 - ntdll:threadpool - impacted 15 MRs
* Bug 54078 - ntdll:pipe - impacted 11 MRs
* Bug 54140 - mmdevapi:render - impacted 5 MRs
* Bug 54005 - ole32:clipboard - impacted 5 MRs
* Bug 54037 - user32:msg - impacted 5 MRs
* Bug 54074 - ws2_32:sock - impacted 5 MRs
I classified the TestBot / GitLab CI results as follows:
* False positive
Cases where the CI system incorrectly claimed the MR introduces new
failures. This is typically the case when the failures that are
already present in nightly WineTest results.
* Bad merge
MRs that break a test and got merged anyway.
* Collateral Damage from a bad merge
The false positives (aka collateral damage) caused by one of the bad
merges above.
* Outside interference
This identifies false positives that are not random and intrinsic to
the test but that result from change outside the Wine infrastructure,
for instance certificates that expire, or configuration changes to
servers that break the tests that depend on it.
Of those the only ones that a CI can really avoid are the first type,
aka "False positive". So I calculated the corresponding weekly rate:
Adjusted False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 21.9% | 8.3%
2022-11-21 | 8.0% | 21.6%
2022-11-28 | 14.7% | 28.4%
2022-12-05 | 8.5% | 24.5%
2022-12-12 | 0.0% | 20.0%
Note that the TestBot's 8% rate for the 11-21 week is not representative
because Wine was broken that week (collateral damage) which prevented
the tests from running in Wine, and thus from contributing real "false
positives". Also the 12-12 week is still incomplete obviously.
Even so I think his shows the TestBot is improving.
Here's a list of the incidents for the weeks above:
* 11-14 An external certificate revocation issue caused crypt32:cert to
fail systematically. This impacted 14 merge requests and was fixed in
MR1360.
* 11-17 MR!1399 got merged despite the TestBot detecting that it
prevented 32-bit Wine tests from running to completion. This impacted
39 merge requests. I could have reduced that number if I had been
faster to reconfigure the TestBot to stop running the full 32-bit Wine
test suite. This was fixed in MR!1524.
* 11-17 MR!1398 got merged despite the TestBot detecting that it broke
ntoskrnl.exe:ntoskrnl on Windows 7. This was fixed in MR!1803.
* 11-22 MR!1495 got merged despite the TestBot detecting that it broke
vbscript:run on Windows *. I don't have a record of the impacted MRs
or of when it was fixed.
* 11-23 The b00a831d direct commit broke kernel32:process in Wine. This
got fixed since.
* 12-07 MR!1732 got merged despite the TestBot detecting that it broke
taskschd:scheduler on Windows *. I immediately added a known failure
entry and no MR got impacted. This was fixed in MR!1736.
If not filtering out the failures caused by these incidents, the false
positive rate is:
Raw False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 52.1% | 27.1%
2022-11-21 | 50.0% | 29.5%
2022-11-28 | 20.0% | 33.7%
2022-12-05 | 19.1% | 57.4%
2022-12-12 | 0.0% | 20.0%
I think that also shows that the TestBot is improving.
I have attached the raw data I collected and shell snippets to
extract various statistics (failures-mr.txt) as well as a spreadsheet
import (failures.xls).
--
Francois Gouget <fgouget(a)codeweavers.com>
When using GCC 12, there's two bogus warnings in Wine's code:
../wine-git/dlls/winex11.drv/clipboard.c: In function
‘X11DRV_CLIPBOARD_GetProperty’:
../wine-git/dlls/winex11.drv/clipboard.c:1871:13: error: pointer ‘val’ may be
used after ‘realloc’ [-Werror=use-after-free]
1871 | free( val );
| ^~~~~~~~~~~
../wine-git/dlls/winex11.drv/clipboard.c:1866:17: note: call to ‘realloc’ here
1866 | *data = realloc( val, pos * sizeof(int) + count + 1 );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real issue here, it's just a false positive.
This could be worked around using a temporary void* variable to hold the
result from realloc.
Is this worth it or would you wait for gcc to fix their warning?
Regards,
Fabian Maurer
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.11 (502 patches are applied to wine vanilla)
vk3d3 has been updated to the 1.8 release.
Upstreamed (Either directly from staging or fixed with a similar patch).
* None
Added:
* [22904] Register URL protocol handlers under linux.
* PR 3124 - Improve performance of Registry writes.
Updated:
* vkd3d-latest (1.8)
* gdiplus-Performance-Improvements
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Hey folks,
As you may have seen, I recently stepped back from my role at
CodeWeavers. [1] I'm still around, just in a greatly reduced fashion.
I am still deeply invested in the success of Wine and plan to remain on
the committee.
Also, this is a good excuse to remind folks of the basic organizational
structure of the Wine Project, which is described here:
https://wiki.winehq.org/Project_Organization
Effectively, this is a heads up that I will be a little less engaged.
That may leave a bit of a void; as always, constructive help is always
welcome.
Cheers,
Jeremy
[1]
https://www.codeweavers.com/blog/jwhite/2023/5/19/a-new-chapter-for-codewea…
So as far as I understand all that's needed to build Wine with the
new Windows-on-Windows support is to do:
./configure --enable-archs=i386,x86_64
make
But then when I run WineTest I get 60+ failures instead of the usual ~16
on my machine.
https://test.winehq.org/queue/err5z_5H/reporthttps://test.winehq.org/queue/errloGNj/report
That does not entirely surprise me since this mode has never been tested
(neither GitLab nor the TestBot support it). But did I miss something?
For instance one failure I get is with devenum:devenum:
devenum:devenum start dlls/devenum/tests/devenum.c
devenum.c:691: Test failed: Got hr 0x80004005.
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00405a75).
The reason for the crash is that wg_transform_create() in main.c returns
NULL:
if (WINE_UNIX_CALL(unix_wg_transform_create, ¶ms))
return NULL; // <---- we return NULL here
without actually calling the implementation in wg_transform.c as far as
I can see.
Here's the list of test units that fail in one of the runs. Lots of
Direct3D (but not all) and multimedia (GStreamer?) tests. Maybe there
are some quick gains to be had?
(then there's msvcrt:file which gets -2 as a file descriptor)
advapi32:security
amstream:amstream
comctl32:subclass
d2d1:d2d1
d3d10core:d3d10core
d3d11:d3d11
d3d8:visual
d3d9:visual
d3dcompiler_43:hlsl_d3d11
d3dcompiler_43:hlsl_d3d9
d3dcompiler_46:hlsl_d3d11
d3dcompiler_46:hlsl_d3d9
d3dcompiler_47:hlsl_d3d11
d3dcompiler_47:hlsl_d3d9
d3dx10_34:d3dx10
d3dx10_35:d3dx10
d3dx10_36:d3dx10
d3dx10_37:d3dx10
d3dx10_38:d3dx10
d3dx10_39:d3dx10
d3dx10_40:d3dx10
d3dx10_41:d3dx10
d3dx10_42:d3dx10
d3dx10_43:d3dx10
d3dx9_36:core
d3dx9_36:math
d3dx9_36:texture
d3dx9_36:volume
dbghelp:dbghelp
ddraw:d3d
ddraw:visual
devenum:devenum
explorer.exe:explorer
gdi32:font
iphlpapi:iphlpapi
kernel32:debugger
kernel32:thread
kernel32:virtual
mfmediaengine:mfmediaengine
mfplay:mfplay
mf:mf
mf:transform
msvcrt:file
msvfw32:mciwnd
ntdll:info
ntdll:virtual
ntdll:wow64
opengl32:opengl
qasf:asfreader
qedit:mediadet
quartz:filtergraph
quartz:vmr7
quartz:vmr9
riched20:editor
user32:class
user32:clipboard
user32:msg
user32:win
win32u:win32u
wininet:internet
winmm:mci
wmp:media
wmvcore:wmvcore
--
Francois Gouget <fgouget(a)codeweavers.com>
Dear Wine Staging maintainers,
I would like to drop the Wine Staging patch that changes `wine
foo.exe` to `/usr/bin/wine foo.exe` in the .desktop files that
winemenubuilder creates.[1] I'm guessing that the wine-devel mailing
list is the best forum is for discussing it because the patch has no
associated Bugzilla report and merge requests are disabled in the
wine-staging repository.
This patch isn't very useful in practice because most (if not all)
Linux distributions have mutually exclusive packages for Wine and Wine
Staging. From the package maintainer's perspective, not supporting the
installation of multiple versions of Wine simultaneously makes a lot
of sense because only one wineserver can run at a time. Moreover, we
don't want to encourage the practice of installing multiple versions
of Wine in order to get everything working. Instead, patches should be
improved and merged into upstream Wine. Once the bugs are fixed
upstream, the user should be free to switch from Wine Staging to
mainline Wine without having to edit all of their .desktop files.
Also... The patch conflicts with the winemenubuilder protocol
associations patch that I'd like to get into Wine Staging,[2] so
dropping it means less work to get the other patch in ;-)
-Alex
[1] https://gitlab.winehq.org/wine/wine-staging/-/blob/adda594159dcafc5dc8db820…
[2] https://gitlab.winehq.org/wine/wine/-/merge_requests/2740
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.10 (500 patches are applied to wine vanilla)
In the spirit of testing, Wine Staging is now going to carry the latest
vk3d3.
Upstreamed (Either directly from staging or fixed with a similar patch).
* ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID range.
* ntdll: Support MEM_COALESCE_PLACEHOLDERS in NtFreeVirtualMemory().
* ntdll: Factor out unmap_view_of_section() function.
* ntdll: Support MEM_PRESERVE_PLACEHOLDER in NtUnmapViewOfSectionEx().
Added:
* [54034] d3dx9: Improve sprite rendering state handling.
* [20732] oleaut32: OleLoadPictureEx - First look for specific icon size
if specified.
* [54998] dnsapi: DnsQuery(DNS_TYPE_SRV) fails to parse some of the
server answers
Updated:
* vkd3d-latest
* winex11-_NET_ACTIVE_WINDOW
* msxml3-FreeThreadedXMLHTTP60
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Thanks for your reply,
I agree, but seeing how old the issue is, I don't know how fast it will be
fixed.
I noticed it's not really fixable when compiling with -O2, it behaves
differently from -O0. At least I didn't find a reliable way (except for ignoring
realloc failure)
There is already a bunch of gcc tickets regarding Wuse-after-free issues, see
meta bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075
I think the closest to our case is https://gcc.gnu.org/bugzilla/show_bug.cgi?
id=106578
Regards,
Fabian Maurer
On Samstag, 10. Juni 2023 10:17:39 CEST you wrote:
> > Is this worth it or would you wait for gcc to fix their warning?
>
> I asked my self the very same question...
>
> given the very low number of warnings from GCC12 (compared to what we
> got with GCC11) and their false positive nature, I'd rather pick the
> wait and see road
>
> perhaps opening a GCC ticket could be useful (so we'd know if there's a
> chance for a fix or if we'll have to fix it on our side)
>
> (reminder: if nothing is done, Alexandre will fix it when he upgrades
> his compiler as he compiles with -Werror)
>
> A+
