On windows, we get some test failures as un-expected thread
create debug events are sent.
Try to filter them out in a couple of places.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Current test in debugger expects that all breakpoint debug
events appear before all the exit thread events.
On Windows, it happens that sometimes the breakpoint and exit
thread events are intertwined (making the test fail).
So, this patch:
- merges the exception events loop and the exit thread events loop
into a single loop.
- detects the unordered sequence (mark it broken as windows only)
- extends the test so that we check that all exit thread events
are received.
- introduce next_event_filter helper to not return some unwanted
events.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47874
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
WriteConsole (not in processed mode) and WriteConsoleOutput* functions
allow to write control characters, which can then be read back as is.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Win10 and Win11 can have some variations in debug events order
(linked to when thread start debug event are generated).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54159
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Even if there's a synchronisation mechanism between kernel32:debugger
and its children which ensures that child has finished writing to and
closed the blackbox logging file before reading it, there's no
guarantee that the file is not re-opened by another process: antivirus,
file indexing...
And according to [1], even the OS itself can still have opened references
to it.
So, always open/read the blackbox file in read share mode to work around
this issue.
Also, harden the code for potential errors, and be nicer in where
failures come from.
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-cleanup
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53456
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Investigating the test failures in MR!1823, it turns out
that sometimes in Win7, at process exit, not all the dll unload
debug events are sent (in traces, only the last loaded dll gets the
event).
I don't know what it only shows now :-(, but that seems very
replicable (it happens every time with new job to TestBot).
So mark the case of missing unload dll debug event as broken
(still checking that the load dll debug event has been received).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Testing: kernel32:debugger, there's sometimes the following error:
debugger.c:1760: Test failed: unexpected instruction pointer 778B2A0C
Current test code has a workaround when this happens on last thread, but
this is clearly not sufficient.
Fix the test so that it grabs the thread context only in a place we're
sure it's in stopped state at breakpoint instruction.
(Current code likely catches cases where the thread is in bp signal
handling).
Rewrote the test to be in more logical order.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53143
On Windows processes sometimes start during test_services_exe() so that
the size returned by the first NtQuerySystemInformation() is no longer
sufficient for the second call.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54094
This effectively reverts 2be9b0ff4a, which
incorrectly removed the flag, when the reallocation failures the tests
showed were coming from an underlying LFH in-place reallocation failure.
Thus, it restores todo_wine where appropriate while removing other todos
for sizes outside of the LFH block size range.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53996
In place reallocation is possible, although it depends on the underlying
heap strategy. The LFH heap usually fails as it doesn't blocks to grow
or shrink out of their size class. Larger block (LFH is limited to 16K
blocks), more often allow in-place reallocation, and some native DLLs
depend on this.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53996
Making the GlobalReAlloc tests more sensible, as they fail to reallocate
when the block was allocated with the LFH and the new size wouldn't.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54012
Current test tries to ensure that a handle, valid in process parent,
hasn't been inherited, but nothing guarantees that a valid handle
isn't present in child process with same value.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Adding the same user flags as native, for Global/Local allocs, and
returning the pointer from Global/LocalHandle by default.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53741
