--
v2: user32/tests: Process messages while waiting in WindowFromPoint tests.
user32/tests: Check for window class registration failure normally.
user32/tests: Remove SetForegroundWindow success checks.
user32/tests: Remove unnecessary test skipping checks.
user32/tests: Fix indentation to silence a warning.
https://gitlab.winehq.org/wine/wine/-/merge_requests/169
Currently, the two methods of setting thread names in Windows
(SetThreadDescription() and the 0x406D1388 exception) log to different channels.
I think it would be useful for these to both log to the same +threadname
channel. My thinking is that this would be similar to +debugstr, in that
all messages are human-readable descriptions which would be useful for
debugging crashes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/89
This (in particular, the “explorer: …” commit) caused a regression for me. In an entirely headless configuration (configured with `--without-x`) on arm32 (probably happens on other architectures too, but that’s where it happened for me), when bootstrapping a new wineprefix (setting `WINEPREFIX` to a new, nonexistent directory, running `wine wineboot`), it can hang, printing errors like these:
```
0048:err:sync:RtlpWaitForCriticalSection section 7BC8A3F0 "../src/dlls/ntdll
/loader.c: …
[View More]loader_section" wait timed out in thread 0048, blocked by 0054, r
etrying (60 sec)
0048:err:sync:RtlpWaitForCriticalSection section 7BC8A3F0 "../src/dlls/ntdll
/loader.c: loader_section" wait timed out in thread 0048, blocked by 0054, r
etrying (60 sec)
```
Does this trigger some race condition when bootstrapping the environment?
(I can report it in bugzilla later, I presume that’s still preferred, I just happened to have better access to gitlab.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/162#note_1460
[View Less]
Signed-off-by: Piotr Caban <piotr(a)codeweavers.com>
---
v2:
- include patch with tests (no changes to patches 1..5)
dlls/d3dx10_43/async.c | 4 ++++
1 file changed, 4 insertions(+)
This allows specifying different expected errors for 32-bit and 64-bit
report files. This is in particular needed when trying to match Wine
exception messages since they contain the bitness.
Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com>
---
testbot/tests/TestWTBS | 49 ++++++++++++++++++++++++++++++++----------
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/testbot/tests/TestWTBS b/testbot/tests/TestWTBS
index e5cd44832..139f011ef 100755
--- a/testbot/tests/…
[View More]TestWTBS
+++ b/testbot/tests/TestWTBS
@@ -337,7 +337,7 @@ sub LoadTestInfo($)
foreach my $RawGroupName (@{$RawInfo->{ErrGroupNames}})
{
my $GroupName = lcfirst($RawGroupName);
- if ($GroupName =~ s/^(tasks|tests|build|win|win32|win64|wine|wine:build|wine:test|wine:module)\.(report|log|testbot)\.//)
+ if ($GroupName =~ s/^(tasks|tests|build|win|win32|win64|wine|wine:build|wine:test|wine:module)\.(win32|wow32|wow64|report|log|testbot)\.//)
{
my $ErrInfo = ($TestInfo->{$1}->{"$2.errors"} ||= {});
push @{$ErrInfo->{ErrGroupNames}}, $GroupName;
@@ -381,8 +381,8 @@ sub LoadTestInfo($)
if (ref($SrcVal) eq "HASH" and $Field !~ /\.errors$/)
{
# Simply propagating hashtable references would result in changes to
- # win32 to impact the parent win / test parent which is not what we
- # want. So subsets of properties are not supported.
+ # win32 to impact the win / test parent which is not what we want.
+ # So subsets of properties are not supported.
# .errors properties are the exception because their values are a
# LoadLogErrors() structure. As a result they are read-only, and are
# not merged.
@@ -445,7 +445,7 @@ sub LoadTestInfo($)
foreach my $TaskType ("tasks", "tests", "build", "win", "win32", "win64",
"wine", "wine:build", "wine:test", "wine:module")
{
- foreach my $LogType ("report", "log", "testbot")
+ foreach my $LogType ("win32", "wow32", "wow64", "report", "log", "testbot")
{
my $Array = $TestInfo->{$TaskType}->{"$LogType.$GrepType"};
next if (!defined $Array);
@@ -483,6 +483,30 @@ sub LoadTestInfo($)
SetDefault($TestInfo, "webpatch", "Status", $Status);
}
+ # Propagate the 'report.*' settings to win32, wow32 and wow64
+ foreach my $TaskType ("wine", "wine:build", "wine:test", "wine:module")
+ {
+ my $TaskInfo = $TestInfo->{$TaskType};
+ foreach my $ReportField (keys %$TaskInfo)
+ {
+ next if (!$ReportField =~ /^report\./);
+ if (ref($TaskInfo->{$ReportField}) eq "HASH" and
+ $ReportField !~ /\.errors$/)
+ {
+ # See the previous task-type propagation comment.
+ fail("internal error: $TaskType.$ReportField should not be a hash in $FileName");
+ next;
+ }
+ foreach my $LogType ("win32", "wow32", "wow64")
+ {
+ my $LogField = $ReportField;
+ $LogField =~ s/^report/$LogType/;
+ next if (defined $TaskInfo->{$LogField});
+ $TaskInfo->{$LogField} = $TaskInfo->{$ReportField};
+ }
+ }
+ }
+
return $TestInfo;
}
@@ -643,13 +667,14 @@ sub IsTimeoutError($$)
}
=pod
-=item <tasks.(report|log|testbot).groupname>
+=item <tasks.(win32|wow32|wow64|report|log|testbot).groupname>
Verifies the presence of new errors in the specified error log or report
of the tasks in the specified category. For this, list the group and errors
that are expected to appear; where the group name is prefixed by the task
-category and either 'report' for the test reports, 'log' for 'task.log', or
-'testbot' for 'testbot.log'.
+category and either 'win32' for 'win32.report', 'wow32' for 'wow32.report',
+'wow64' for 'wow64.report', 'report' for any of the test reports,
+'log' for 'task.log', or 'testbot' for 'testbot.log'.
For instance:
g 0 tests.report.kernel32
@@ -678,7 +703,7 @@ Finally, note that while the error directives are inherited by subcategories,
they are not merged. So if both win and win32 have error-matching directives,
win32 will not inherit anything from the win category.
-=item <tasks.(report|log|testbot).Errors>
+=item <tasks.(win32|wow32|wow64|report|log|testbot).Errors>
Inheritance of the reference error lists cannot be prevented but can be ignored
by setting this property to 'ignore'.
@@ -856,8 +881,8 @@ depend on whether the test was the last one run by the task (in the Wine case).
By default this check is skipped and timeout errors are reported like any
other unexpected error.
-=item <tasks.(report|log|testbot).Grep>
-=item <tasks.(report|log|testbot).GrepV>
+=item <tasks.(win32|wow32|wow64|report|log|testbot).Grep>
+=item <tasks.(win32|wow32|wow64|report|log|testbot).GrepV>
Verifies the presence or absence of specific regular expressions in the
specified error log or reports of the tasks in the specified category.
@@ -940,7 +965,9 @@ sub CheckTask($$$$)
my $LogType = "log";
if ($LogName =~ /\.report$/)
{
- $LogType = "report";
+ $LogType = $LogName =~ /^wow32/ ? "wow32" :
+ $LogName =~ /^wow64/ ? "wow64" :
+ "win32";
$ReportCount++;
ok($ReportTypes{$LogName}, "Check that $LogName is expected");
--
2.30.2
[View Less]
On certain dual GPU configurations (AMD integrated / discrete GPU laptop in my case) vkGetRandROutputDisplayEXT() doesn't work the way we currently expect. That is, it returns success and a valid VkDisplay handler for any randr provider and GPU combination. The configuration ends up broken in various aspects, the same GPU gets added twice with identical parameters while another GPU is not represented at all.
I think it is not a Vulkan or xrandr bug, this behaviour probably reflects the fact …
[View More]that one can present from any of Vulkan devices to the displays plugged to any of those outputs.
The patch avoids adding the device twice and also another device gets represented as well. The relation between the added GPUs and monitors ends up being somewhat arbitrary but then it doesn't affect much in the case when displays are accessible though any of adapters.
The alternative to consider would be to have a completely separate path to be taken if Vulkan is available which instead of attaching Vulkan device info to xrandr-driven GPUs list would have GPU device spawned by Vulkan device and use xrandr to link the adapters and displays to GPUs. This way it would also help Wayland where we don't have real xrandr providers (only one WAYLAND provider with all the displays) and end up without creating proper GPU devices.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/164
[View Less]
__fastfail() is used by the Visual C++ runtime and Windows system
libraries to signal that the in-process state is corrupted and
unrecoverable.
If __fastfail() is invoked, the NT kernel raises a second-chance
non-continuable exception STATUS_STACK_BUFFER_OVERRUN. This quickly
terminates the process, bypassing all in-process exception handlers
(since they all rely on the potentially corrupted process state).
--
v2: ntdll: Properly parse UDF instruction in ARM.
ntdll: Implement …
[View More]__fastfail().
ntdll/tests: Add tests for __fastfail().
include: Define fast fail codes and the __fastfail() intrinsic.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9
[View Less]
Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com>
--
v3: d3d9/tests: Extend color_fill_test.
wined3d: Store clear colors in subresources.
wined3d: Handle WINED3DFMT_D32_FLOAT in wined3d_format_convert_from_float.
wined3d: Prepare sysmem LOCATION_CLEARED handling for non-zero colors (v2).
wined3d: Add a memory_colour_fill path for clearing the entire level to zero.
https://gitlab.winehq.org/wine/wine/-/merge_requests/109
Andew, thanks for the build.
Here is the patch with Signed-off-by line.
Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com>
---
dlls/winecoreaudio.drv/coremidi.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
--
v2: ntdll: Remove tail checking on large blocks.
ntdll: Merge common resize case in heap_realloc.
ntdll: Call valgrind alloc notifications at the topmost level.
ntdll: Correctly free pending pointer in RtlDestroyHeap.
ntdll: Split valgrind memory access control to separate helpers.
ntdll: Fix handling of back pointer in heap_set_debug_flags.
https://gitlab.winehq.org/wine/wine/-/merge_requests/159
This serie tackles several issues encountered while loading PDB files through dbghelp.
It happens that PDB allows to have several type records for user defined types (struct / enums)
with the same name.
This seems to be generated by a) compiler (when modifying a structure definition between several
compilation phases), b) the incremental linker (likely an optimisation of previous case, but
not 100% certain when it's triggered).
Wine's dbghelp ended up not picking the right record, hence …
[View More]generating errneous outputs.
This series:
- cleans up some PDB related code
- update winedump to display the PDB hash table internals
- fixes dbghelp to preserve in Wine's dbghelp hash table the partial order between type
records of same name.
v2:
- rebased
- removed a bunch of stray comments
--
v3: dlls/dbghelp{pdb}: use remap table from PDB hash stream
dlls/dbghelp{pdb}: ensure dbghelp's list order in hash table matches PDB's
dlls/dbghelp{pdb}: clearly separate the type loading into two passes
include/wine/mscvpdb.h: redefine property with bitfields
dlls/dbghelp{pdb}: rely on first/last index from type header
tools/winedump{pdb}: explore a bit more TPI hash elements
https://gitlab.winehq.org/wine/wine/-/merge_requests/73
[View Less]
This serie tackles several issues encountered while loading PDB files through dbghelp.
It happens that PDB allows to have several type records for user defined types (struct / enums)
with the same name.
This seems to be generated by a) compiler (when modifying a structure definition between several
compilation phases), b) the incremental linker (likely an optimisation of previous case, but
not 100% certain when it's triggered).
Wine's dbghelp ended up not picking the right record, hence …
[View More]generating errneous outputs.
This series:
- cleans up some PDB related code
- update winedump to display the PDB hash table internals
- fixes dbghelp to preserve in Wine's dbghelp hash table the partial order between type
records of same name.
--
v2: dlls/dbghelp{pdb}: use remap table from PDB hash stream
dlls/dbghelp{pdb}: ensure dbghelp's list order in hash table matches PDB's
dlls/dbghelp{pdb}: clearly separate the type loading into two passes
include/wine/mscvpdb.h: redefine property with bitfields
dlls/dbghelp{pdb}: rely on first/last index from type header
tools/winedump{pdb}: explore a bit more TPI hash elements
https://gitlab.winehq.org/wine/wine/-/merge_requests/73
[View Less]
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v2: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155