The ntoskrnl output is now very reasonable. Many thanks to Zebediah for taking care of this.
But the WineTest reports are, again, above the 1.5 MB size limit on Wine. Not by much, from 22 to 90kB, but that's enough to cause a lot of Wine results to disappear from test.winehq.org:
https://test.winehq.org/data/patterns.html (notice the underscores at the end of the linux_ lines)
The limit could be raised (if Alexandre accepts the patch), but we also cannot let the tests output increase without control if we want to keep reasonable file sizes. If all tests outputted as much as the top 5 we would have 40 MB test reports which would have a serious impact on the test.winehq.org disk usage. It also means the 'full report' HTML pages would blow up to about 152 MB. That might prove hard on web browsers.
So maybe increasing the limit is necessary and maybe even overdue. But it's also the easy way out and the top 5 offenders (see list at bottom) are clearly generating too much output anyway. So I think we should make some effort to bring them to more reasonable sizes.
Anyway, the main tests responsible for the size increase are: * user32:msg (+63kB) * dinput8:hid (+26kB) * and a smattering of d3d tests
Also this time there is no single patch to blame. Instead a range of patches added 105kB to the reports, pushing them over the edge:
Sep 08: d3dcompiler_46:hlsl_d3d11 (new, +1.7kB) d3dx10_38:d3dx10 (new, +3kB) user32:msg (+6kB)
Sep 09: dinput8:hid (new, +4kB) user32:msg (+18kB) Sep 13: d3dx10_37:d3dx10 (new, +3kB)
Sep 15: dinput8:hid (+3kB) Sep 15: d3dx10_36:d3dx10 (new, +3kB)
Sep 16: dinput8:hid (+3kB)
Sep 17: dinput8:hid (+10kB) user32:msg (+6kB)
Sep 20: dinput8:hid (+7kB) d3dx10_35:d3dx10 (new, +3kB) user32:msg (+15kB)
Sep 21: user32:msg (+19kB)
Of course we still have the old offenders so that the top 5 tests (1.36% of the total) now use 17% (270kB) of the maximum report size!
So I created bugs to track this and I'm calling for help to get this under control:
* bug 51780 - user32:msg (97kB) * bug 51781 - d3d11:d3d11 (84kB) * bug 51782 - ws2_32:sock (29kB) * bug 51783 - ieframe:webbrowser (29kB) * bug 51785 - d3dx10_*:d3dx10 (29kB) * bug 51784 - dinput8:hid (26kB) (not in top 5 if aggregating d3dx10_*)
Note: Yes, I'm using 1000 bytes kBs here: I have an easier time dividing the 'wc -c' output by 1000 in my head than by 1024.
The increase in size of user32:msg on wine is due to the fact we're actually now testing for Winevents in the tests rather than just skipping/ignoring them. Once I have the tests fixed up, I intend on adding support for at least EVENT_OBJECT_FOCUS, and then figuring out which others can be implemented without too much work. EVENT_OBJECT_DESTROY should be another easy one.
Anyways, even with those out of the way, there still may be quite a few todo's. I don't know if there's a smart way to 'silence' them without losing useful output. I guess we could just accrue a count of winevents that were marked todo per sequence test, but that makes it harder to see what needs fixed. I will try to look into this once I have all of the sequences fixed. Sorry for the extra log length :/
On 9/23/21 5:17 PM, Francois Gouget wrote:
The ntoskrnl output is now very reasonable. Many thanks to Zebediah for taking care of this.
But the WineTest reports are, again, above the 1.5 MB size limit on Wine. Not by much, from 22 to 90kB, but that's enough to cause a lot of Wine results to disappear from test.winehq.org:
https://test.winehq.org/data/patterns.html (notice the underscores at the end of the linux_ lines)
The limit could be raised (if Alexandre accepts the patch), but we also cannot let the tests output increase without control if we want to keep reasonable file sizes. If all tests outputted as much as the top 5 we would have 40 MB test reports which would have a serious impact on the test.winehq.org disk usage. It also means the 'full report' HTML pages would blow up to about 152 MB. That might prove hard on web browsers.
So maybe increasing the limit is necessary and maybe even overdue. But it's also the easy way out and the top 5 offenders (see list at bottom) are clearly generating too much output anyway. So I think we should make some effort to bring them to more reasonable sizes.
Anyway, the main tests responsible for the size increase are:
- user32:msg (+63kB)
- dinput8:hid (+26kB)
- and a smattering of d3d tests
Also this time there is no single patch to blame. Instead a range of patches added 105kB to the reports, pushing them over the edge:
Sep 08: d3dcompiler_46:hlsl_d3d11 (new, +1.7kB) d3dx10_38:d3dx10 (new, +3kB) user32:msg (+6kB)
Sep 09: dinput8:hid (new, +4kB) user32:msg (+18kB) Sep 13: d3dx10_37:d3dx10 (new, +3kB)
Sep 15: dinput8:hid (+3kB) Sep 15: d3dx10_36:d3dx10 (new, +3kB)
Sep 16: dinput8:hid (+3kB)
Sep 17: dinput8:hid (+10kB) user32:msg (+6kB)
Sep 20: dinput8:hid (+7kB) d3dx10_35:d3dx10 (new, +3kB) user32:msg (+15kB)
Sep 21: user32:msg (+19kB)
Of course we still have the old offenders so that the top 5 tests (1.36% of the total) now use 17% (270kB) of the maximum report size!
So I created bugs to track this and I'm calling for help to get this under control:
- bug 51780 - user32:msg (97kB)
- bug 51781 - d3d11:d3d11 (84kB)
- bug 51782 - ws2_32:sock (29kB)
- bug 51783 - ieframe:webbrowser (29kB)
- bug 51785 - d3dx10_*:d3dx10 (29kB)
- bug 51784 - dinput8:hid (26kB) (not in top 5 if aggregating d3dx10_*)
Note: Yes, I'm using 1000 bytes kBs here: I have an easier time dividing the 'wc -c' output by 1000 in my head than by 1024.
I'm the one to blame for dinput8:hid blowing up, so of course I'm completely biased, but looking at it again it doesn't seem to be *that much* out of control.
Even with the tests I intend to fix, I think it will only reduce to maybe half its current output size.
There's a lot of redundant test driver installation todos, but mostly because of how the tests need to be run. Of course I could just remove these checks, but I don't like the idea very much...
So then my question is, is there any actual use for the full reports (even more for their HTML version)?
And then, I suppose these are all uncompressed sizes, so could we compress the reports if this is a matter of disk space? I'm sure they would compress pretty well.
Cheers,
-
Connor McAdams -
Francois Gouget -
Rémi Bernon