[Bug 55721] New: ntdll:info - The 64-bit test_query_process_vm() unexpectedly succeeds on Debian 12
https://bugs.winehq.org/show_bug.cgi?id=55721
Bug ID: 55721 Summary: ntdll:info - The 64-bit test_query_process_vm() unexpectedly succeeds on Debian 12 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
ntdll:info - The 64-bit test_query_process_vm() unexpectedly succeeds on Debian 12:
info.c:1928: Test succeeded inside todo block: Expected to be greater than 335220736, got 336269312 info.c:1945: Test succeeded inside todo block: Expected to be greater than 336269312, got 336269312
See https://test.winehq.org/data/patterns.html#ntdll:info
An unexpected success may be better than an unexpected failure but it's treated as a failure regardless.
This started on 2023-09-28 so it may be related to the low address space reservation changes commits made on that day. This is systematic but only impacts some test configurations so it would be interesting to understand why: * fgtb-debian12-wow64 -> unexpected success * fgtb-debian12-x86-64 -> unexpected success * newtb-debian12-wow64 -> unexpected success * gitlab-debian-64 -> todo as expected (despite being Debian 12 too!) * fgtb-debian11-* -> todo as expected * newtb-debian11-* -> todo as expected * newtb-debiant-* -> todo as expected (post-Debian 12 Debian Testing)
https://bugs.winehq.org/show_bug.cgi?id=55721
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=55721
--- Comment #1 from François Gouget fgouget@codeweavers.com --- I cannot reliably reproduce this issue. * Using the very script used by my TestBot I had a 50% success rate (out of 2 tries). * But I was never able to reproduce the issue when trying to bisect the issue, even if running all the tests like in the nightly WineTest runs.
The test allocates 16 MB and checks whether that's reflected in the memory returned by NtQueryInformationProcess(ProcessVmCounters). The implementation relies on the VMSize value in /proc/pid/maps. But the documentation says:
| Some of these values are inaccurate because of a kernel- | internal scalability optimization. If accurate values are | required, use /proc/pid/smaps or /proc/pid/smaps_rollup | instead, which are much slower but provide accurate, | detailed information.
I understand this as meaning VmSize may be a bit out-of-date which explains the failure case. But that still does not explain why in some cases it is reliably up-to-date.
Anyway, one fix may be to switch to /proc/pid/smaps as suggested by the documentation. That depends on whether accuracy or performance is more important for this API.
Another may be to just try the call a couple of time to give /proc/pid/maps time to catch up (e.g. using the tryok mechanism).
-
WineHQ Bugzilla