[Bug 52892] New: The 64-bit ntdll:thread fails on w7pro64 and w864

[WineHQ Bugzilla]

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

            Bug ID: 52892
           Summary: The 64-bit ntdll:thread fails on w7pro64 and w864
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ntdll
          Assignee: wine-bugs at winehq.org
          Reporter: fgouget at codeweavers.com

The 64-bit ntdll:thread fails on w7pro64 and w864:

thread.c:153: Test failed: Multiple threads have TEB 000007FFFFFDC000.

https://test.winehq.org/data/patterns.html#ntdll:thread


The failure is hard to reproduce but the test was introduced by this commit:

commit 6d4ec1255acceec7152ed98764ee29991ac04f10
Author:     Brendan Shanks <bshanks at codeweavers.com>
AuthorDate: Mon Apr 18 11:25:10 2022 -0700
Commit:     Alexandre Julliard <julliard at winehq.org>
CommitDate: Mon Apr 18 21:48:15 2022 +0200

    ntdll/tests: Test that threads have unique TEBs.

    Signed-off-by: Brendan Shanks <bshanks at codeweavers.com>
    Signed-off-by: Alexandre Julliard <julliard at winehq.org>


Specifically the issue is with the line below:

+    ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 );


I think the issue is that there is no guarantee that the two test threads are
running at the same time. I suspect that sometimes what happens is this [1]:


* status = pNtCreateThreadEx( &threads[0], ... &teb1, ... );
  A new TEB is allocated, the first thread starts, sets teb1 and terminates at
which time its TEB is freed.

* status = pNtCreateThreadEx( &threads[1], ... &teb2, ... );
  A new TEB is allocated, hey there's a fresh TEB that has just bee freed! [2].
The second thread starts and sets teb2.

* WaitForMultipleObjects( 2, threads, TRUE, INFINITE );
  Wait for both threads.

* ok( teb1 != teb2, "Multiple threads have TEB %p.\n", teb1 );
  Hey, both threads used the same TEB!
  But did they do so at the same time?

One hacky fix would be to at a small sleep in the test threads but that's
introducing race conditions. A better fix would be for the main thread to tell
the test threads when they can exit through some synchronization object.


[1] This may be tied to how the scheduler behaves which may limit the issue to
specific Windows versions.
[2] And that's probably tied to how the memory allocator behaves: more memory
locality or less chance of overwriting (incorrectly) still in use memory. Again
this could limit the issue to some Windows versions.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.