[Bug 54498] New: kernel32:heap - The memory information sometimes changes during test_GlobalMemoryStatus() in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=54498

Bug ID: 54498
           Summary: kernel32:heap - The memory information sometimes
                    changes during test_GlobalMemoryStatus() in Wine
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: kernel32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

kernel32:heap - The memory information sometimes changes during
test_GlobalMemoryStatus() in Wine.

This causes a failure when the available physical or page file information is
checked:

heap.c:3595: Test failed: got ullAvailPhys 0x14e7f00000
heap.c:3597: Test failed: got ullAvailPageFile 0x33a85ff000

Unfortunately this does not specify the expected value :-(

This never happens in during the nightly WineTest runs or in TestBot jobs but
has impacted a number of merge requests (e.g. MR2213, MR2094, MR2078, MR1499).

I can also sometimes reproduce it on my desktop. I think the trick to
reproducing it is to have some other activity on the system that causes a lot
of memory to be allocated or freed while this test is running. Looping on
test_GlobalMemoryStatus() calls also helps.

The test already assumes the data may change but it only allows -/+1MB which is
way too narrow. From some additional traces in MR2213:

memex-expect: Phys: 0x16e1861000 - 0x16e60eb000 = -76062720 / 0x1f5e3fc000 -
0x1f5e3fc000 = 0 PageFile 0x3452460000 - 0x3456cea000 = -76062720 /
0x3f483fc000 - 0x3f483fc000 = 0

During that run the total change in AvailPhys was 305 MB so I don't think
allowing an interval makes sense. It's better to loop and check that we can get
matching values in a few tries.

But then 4d122a26e56a went in the other direction, but did not specify why.