This allows figuring out which function the crash happens in when there is no backtrace. Just set WINETEST_NO_MT_D3D=1 WINETEST_DEBUG=2.
Signed-off-by: Francois Gouget fgouget@codeweavers.com --- The patch decodes the feature level before printing it but maybe that's presuming too much and a simple %04x would be better. --- dlls/d3d11/tests/d3d11.c | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c index d412f430b60..29f8c7ce831 100644 --- a/dlls/d3d11/tests/d3d11.c +++ b/dlls/d3d11/tests/d3d11.c @@ -49,6 +49,7 @@ static struct test_entry void (*test)(void); void (*test_fl)(D3D_FEATURE_LEVEL fl); } u; + const char* name; D3D_FEATURE_LEVEL fl; } *mt_tests; size_t mt_tests_size, mt_test_count; @@ -121,21 +122,25 @@ static void queue_test_entry(const struct test_entry *t) mt_tests[mt_test_count++] = *t; }
-static void queue_test_fl(void (*test)(const D3D_FEATURE_LEVEL fl), D3D_FEATURE_LEVEL fl) +#define queue_test_fl(f,fl) _queue_test_fl(f,#f,fl) +static void _queue_test_fl(void (*test)(const D3D_FEATURE_LEVEL fl), const char* name, D3D_FEATURE_LEVEL fl) { struct test_entry t;
t.u.test_fl = test; t.fl = fl; + t.name = name; queue_test_entry(&t); }
-static void queue_test(void (*test)(void)) +#define queue_test(f) _queue_test(f,#f) +static void _queue_test(void (*test)(void), const char* name) { struct test_entry t;
t.u.test = test; t.fl = 0; + t.name = name; queue_test_entry(&t); }
@@ -172,6 +177,7 @@ static void run_queued_tests(void) { for (i = 0; i < mt_test_count; ++i) { + trace("fl=%d.%d %s\n", mt_tests[i].fl >> 12, (mt_tests[i].fl >> 8) & 0xf, mt_tests[i].name); run_mt_test(&mt_tests[i]); }
@@ -20452,8 +20458,10 @@ static void test_fl9_draw(const D3D_FEATURE_LEVEL feature_level) release_test_context(&test_context); }
-static void queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL begin, - D3D_FEATURE_LEVEL end, void (*test_func)(const D3D_FEATURE_LEVEL fl)) +#define queue_for_each_feature_level_in_range(b,e,f) _queue_for_each_feature_level_in_range(b,e,f,#f) +static void _queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL begin, + D3D_FEATURE_LEVEL end, void (*test_func)(const D3D_FEATURE_LEVEL fl), + const char* name) { static const D3D_FEATURE_LEVEL feature_levels[] = { @@ -20471,20 +20479,24 @@ static void queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL begin, for (i = 0; i < ARRAY_SIZE(feature_levels); ++i) { if (begin <= feature_levels[i] && feature_levels[i] <= end) - queue_test_fl(test_func, feature_levels[i]); + _queue_test_fl(test_func, name, feature_levels[i]); } }
-static void queue_for_each_feature_level(void (*test_func)(const D3D_FEATURE_LEVEL fl)) +#define queue_for_each_feature_level(f) _queue_for_each_feature_level(f,#f) +static void _queue_for_each_feature_level(void (*test_func)(const D3D_FEATURE_LEVEL fl), + const char* name) { - queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL_9_1, - D3D_FEATURE_LEVEL_11_1, test_func); + _queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL_9_1, + D3D_FEATURE_LEVEL_11_1, test_func, name); }
-static void queue_for_each_9_x_feature_level(void (*test_func)(const D3D_FEATURE_LEVEL fl)) +#define queue_for_each_9_x_feature_level(f) _queue_for_each_9_x_feature_level(f,#f) +static void _queue_for_each_9_x_feature_level(void (*test_func)(const D3D_FEATURE_LEVEL fl), + const char* name) { - queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL_9_1, - D3D_FEATURE_LEVEL_9_3, test_func); + _queue_for_each_feature_level_in_range(D3D_FEATURE_LEVEL_9_1, + D3D_FEATURE_LEVEL_9_3, test_func, name); }
static void test_ddy(void)
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=90081
Your paranoid android.
=== w1064v1809 (32 bit report) ===
d3d11: d3d11.c:5817: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5818: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5819: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5822: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5823: Test failed: Got unexpected CPrimitives count: 0.
=== w1064 (32 bit report) ===
d3d11: d3d11.c:5817: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5818: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5819: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5822: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5823: Test failed: Got unexpected CPrimitives count: 0. d3d11.c:5664: Test failed: Got unexpected query result 0x0000000000000000.
=== w10pro64 (32 bit report) ===
d3d11: d3d11.c:5817: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5818: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5819: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5822: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5823: Test failed: Got unexpected CPrimitives count: 0. d3d11.c:5664: Test failed: Got unexpected query result 0x0000000000000000.
=== debiant2 (32 bit Japanese:Japan report) ===
d3d11: d3d11.c:9667: Test failed: d3d11.c:15028: Test marked todo: Got hr 0 for WRITE_DISCARD.
On Fri, 7 May 2021 at 19:39, Francois Gouget fgouget@codeweavers.com wrote:
This allows figuring out which function the crash happens in when there is no backtrace. Just set WINETEST_NO_MT_D3D=1 WINETEST_DEBUG=2.
I'm not necessarily opposed to this (you do seem to have misplaced a number of *'s, as well as some other minor style issues though), but don't the tests already print the last test seen before the exception on Windows? (And we're supposed to have backtraces everywhere else.)
On Mon, 10 May 2021, Henri Verbeet wrote:
On Fri, 7 May 2021 at 19:39, Francois Gouget fgouget@codeweavers.com wrote:
This allows figuring out which function the crash happens in when there is no backtrace. Just set WINETEST_NO_MT_D3D=1 WINETEST_DEBUG=2.
I'm not necessarily opposed to this (you do seem to have misplaced a number of *'s, as well as some other minor style issues though),
I can resubmit with the *s moved over but I don't know what the other issues are.
but don't the tests already print the last test seen before the exception on Windows? (And we're supposed to have backtraces everywhere else.)
Pretty often it does not as is obvious from many test results, and specifically not in this case. I don't know why though.
https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200...
No 'last test seen' message for those either: https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win7_n... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win81_...
So it's not a problem with a specific test, nor with a specific Windows version. If someone knows what's going on...
On Mon, 10 May 2021 at 16:14, Francois Gouget fgouget@codeweavers.com wrote:
On Mon, 10 May 2021, Henri Verbeet wrote:
On Fri, 7 May 2021 at 19:39, Francois Gouget fgouget@codeweavers.com wrote:
This allows figuring out which function the crash happens in when there is no backtrace. Just set WINETEST_NO_MT_D3D=1 WINETEST_DEBUG=2.
I'm not necessarily opposed to this (you do seem to have misplaced a number of *'s, as well as some other minor style issues though),
I can resubmit with the *s moved over but I don't know what the other issues are.
By convention: _queue_test_fl() -> queue_test_fl_() _queue_test() -> queue_test_() _queue_for_each_feature_level_in_range() -> queue_for_each_feature_level_in_range_() _queue_for_each_feature_level() -> queue_for_each_feature_level_() as well as preferring %u over %d in most cases.
but don't the tests already print the last test seen before the exception on Windows? (And we're supposed to have backtraces everywhere else.)
Pretty often it does not as is obvious from many test results, and specifically not in this case. I don't know why though.
https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200...
No 'last test seen' message for those either: https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win200... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win7_n... https://test.winehq.org/data/99e47361a37a4bf16de131401a0c231f86214a43/win81_...
So it's not a problem with a specific test, nor with a specific Windows version. If someone knows what's going on...
Without having debugged it, my first guess would be that perhaps the tls_data structure is getting corrupted somehow. Does that happen consistently for that particular crash? Also, does that still happen with WINETEST_NO_MT_D3D=1? Still, even if this particular functionality happens to be broken in this case, for debug purposes WINETEST_REPORT_SUCCESS=1 could serve much of the same purpose.
On Tue, 11 May 2021, Henri Verbeet wrote:
On Mon, 10 May 2021 at 16:14, Francois Gouget fgouget@codeweavers.com wrote:
On Mon, 10 May 2021, Henri Verbeet wrote:
On Fri, 7 May 2021 at 19:39, Francois Gouget fgouget@codeweavers.com wrote:
This allows figuring out which function the crash happens in when there is no backtrace. Just set WINETEST_NO_MT_D3D=1 WINETEST_DEBUG=2.
I'm not necessarily opposed to this (you do seem to have misplaced a number of *'s, as well as some other minor style issues though),
I can resubmit with the *s moved over but I don't know what the other issues are.
By convention: _queue_test_fl() -> queue_test_fl_() _queue_test() -> queue_test_() _queue_for_each_feature_level_in_range() -> queue_for_each_feature_level_in_range_() _queue_for_each_feature_level() -> queue_for_each_feature_level_() as well as preferring %u over %d in most cases.
I will resubmit with these changes (though technically, being an enum, I doubt D3D_FEATURE_LEVEL is unsigned).
[...]
So it's not a problem with a specific test, nor with a specific Windows version. If someone knows what's going on...
Without having debugged it, my first guess would be that perhaps the tls_data structure is getting corrupted somehow. Does that happen consistently for that particular crash?
Yes. More specifically: * Only cw-gtx560 crashes almost systematically in the d3d11:d3d11 test. * When running Windows 10 cw-gtx560 never gets the 'last trace' message. * When running Windows 8.1 cw-gtx560 sometimes gets the 'last trace' message but that looks like a different crash: the last trace line number does not match. * Machines with rx460 and rx550 GPUs also crash but a bit less often and they never get the 'last trace' message either.
Also, does that still happen with WINETEST_NO_MT_D3D=1?
Yes.
Still, even if this particular functionality happens to be broken in this case, for debug purposes WINETEST_REPORT_SUCCESS=1 could serve much of the same purpose.
True.
On Fri, 14 May 2021 at 12:04, Francois Gouget fgouget@codeweavers.com wrote:
I will resubmit with these changes (though technically, being an enum, I doubt D3D_FEATURE_LEVEL is unsigned).
Sure, but we don't care so much about the type of D3D_FEATURE_LEVEL as about the kind of information stored in it. I.e., a feature level like "-1.-1" isn't all that meaningful. Of course it doesn't make any difference for any of the valid D3D_FEATURE_LEVEL values, but that's the reasoning at least.
Without having debugged it, my first guess would be that perhaps the tls_data structure is getting corrupted somehow. Does that happen consistently for that particular crash?
Yes. More specifically:
- Only cw-gtx560 crashes almost systematically in the d3d11:d3d11 test.
- When running Windows 10 cw-gtx560 never gets the 'last trace' message.
- When running Windows 8.1 cw-gtx560 sometimes gets the 'last trace' message but that looks like a different crash: the last trace line number does not match.
- Machines with rx460 and rx550 GPUs also crash but a bit less often and they never get the 'last trace' message either.
It may be interesting to try printing the contents of the tls_data structure when that crash happens on the cw-gtx560 machine, although it may simply be a case of the graphics driver overwriting it before crashing.
On Fri, 14 May 2021, Henri Verbeet wrote: [...]
It may be interesting to try printing the contents of the tls_data structure when that crash happens on the cw-gtx560 machine, although it may simply be a case of the graphics driver overwriting it before crashing.
As far as I can tell the crash happens in a thread which never called winetest_set_location(). Maybe that's a Direct3D / driver thread. In any case current_file is obviously NULL so the exception handler is unable to show the last test seen before the exception.
Also note that right after the crash I get a Windows notification telling me that "Display driver stopped responding has recovered" (this is with the Game Ready Driver 391.35).
On Mon, 17 May 2021 at 17:43, Francois Gouget fgouget@codeweavers.com wrote:
On Fri, 14 May 2021, Henri Verbeet wrote: [...]
It may be interesting to try printing the contents of the tls_data structure when that crash happens on the cw-gtx560 machine, although it may simply be a case of the graphics driver overwriting it before crashing.
As far as I can tell the crash happens in a thread which never called winetest_set_location(). Maybe that's a Direct3D / driver thread.
Oh, if the exception happens on a thread spawned by the D3D runtime or the graphics driver that would make sense, yes.
Also note that right after the crash I get a Windows notification telling me that "Display driver stopped responding has recovered" (this is with the Game Ready Driver 391.35).
And that seems consistent with that scenario, yes.
-
Francois Gouget -
Henri Verbeet -
Marvin