[Bug 17135] New: virtual write watches cause problems in multithreaded .NET code (simultaneous GC heap allocations)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=17135

           Summary: virtual write watches cause problems in multithreaded
                    .NET code (simultaneous GC heap allocations)
           Product: Wine
           Version: 1.1.13
          Platform: Other
               URL: http://www.microsoft.com/downloads/details.aspx?FamilyID
                    =262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en
        OS/Version: other
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ntdll
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: focht at gmx.net


Created an attachment (id=18992)
 --> (http://bugs.winehq.org/attachment.cgi?id=18992)
Winedbg session of migpolwin

Hello,

while testing some older .NET 1.x stuff I encountered mysterious (rare) install
errors which did not happen until recently.

The problem is caused by the addition of virtual write watch support
(technically a regression).

--- snip ---
$ git bisect good
af8bb2e9222a79cc6ef2fa22c4eac75122eac5de is first bad commit
commit af8bb2e9222a79cc6ef2fa22c4eac75122eac5de
Author: Alexandre Julliard <julliard at winehq.org>
Date:   Tue Nov 25 12:07:35 2008 +0100

    ntdll: Add support for virtual write watches.

:040000 040000 99d51bad8c4d6a32417c8ed53edeee43370bd463
ffc461379b1aa89527cacadc5555d0d9eaa77a56 M      dlls
:040000 040000 eb2d3dc044c246182b50c6fd4650ce0242ad4f4b
3523f1756ea054c4c3ad26f78a8161c46330bb5f M      include
:040000 040000 e4ba31cd1e60853ad020f15bef20883951424793
4f34f4d2a0e87e51a7d53ed15a39b718bbaaa856 M      server

$ wine --version
wine-1.1.9-66-g81b9ca5 
--- snip ---

Unfortunately tracking the problem down is not easy as it exhibits only
sporadically in .NET Framework 1.0 and 1.1 installer.

Multi-core CPU/machines seem to escalate this problem further.

Basically you have to loop .NET Framework 1.1 install again and again in clean
WINEPREFIX until you hit exception dialog.

--- snip ---
$ wine --version
wine-1.1.13-272-gf63d950
--- snip ---

--- loop ---
$ wineserver -k
$ rm -rf .wine
$ wine dotnetfx11.exe /q:a /c:"install.exe /qb /l"
--- loop ---

The installer is almost at its end, running the .NET 1.0 -> 1.1 migration tool.
When the exception dialog pops up, dismiss the message with "OK", the installer
will finish.
Manually run the migration tool thereafter.

If the installer finished without exception dialog, there is no use in manually
re-running the migration tool, it will skip the steps which will lead to
exception.

Some +tid,+seh,+relay,+virtual,+ntdll trace log (multithreaded
execution/output):

Both threads of interest causing faults almost simultaneously:

--- snip ---
...
0032:trace:virtual:virtual_handle_fault 0x47ca000, 1
002f:trace:virtual:virtual_handle_fault 0x47cbffc, 1
0032:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47ca000-0x47cafff
0032:trace:virtual:VIRTUAL_DumpView View: 0x4750000 - 0x674ffff (valloc)
0032:trace:virtual:VIRTUAL_DumpView       0x4750000 - 0x47cafff c-rw-
0032:trace:virtual:VIRTUAL_DumpView       0x47cb000 - 0x47d1fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView       0x47d2000 - 0x574ffff --rw-
0032:trace:virtual:VIRTUAL_DumpView       0x5750000 - 0x5755fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView       0x5756000 - 0x5761fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView       0x5762000 - 0x674ffff --rw-
002f:trace:virtual:VIRTUAL_SetProt 0x47cb000-0x47cbfff c-rw-
002f:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47cb000-0x47cbfff
002f:trace:virtual:VIRTUAL_DumpView View: 0x4750000 - 0x674ffff (valloc)
002f:trace:virtual:VIRTUAL_DumpView       0x4750000 - 0x47cbfff c-rw-
002f:trace:virtual:VIRTUAL_DumpView       0x47cc000 - 0x47d1fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView       0x47d2000 - 0x574ffff --rw-
002f:trace:virtual:VIRTUAL_DumpView       0x5750000 - 0x5755fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView       0x5756000 - 0x5761fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView       0x5762000 - 0x674ffff --rw-
0032:trace:seh:raise_exception code=c0000005 flags=0 addr=0x791b3e04
ip=0x791b3e04 tid=0032
0032:trace:seh:raise_exception  info[0]=00000001
0032:trace:seh:raise_exception  info[1]=047cb000
0032:trace:seh:raise_exception  eax=00000000
ebx=047c002f:trace:virtual:VIRTUAL_SetProt 0x47cc000-0x47ccfff c-rw-
002f:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47cc000-0x47ccfff
--- snip ---

Both "VIRTUAL_SetProt handling write watch" (VIRTUAL_SetProt -> if
(view->protect & VPROT_WRITEWATCH)) and "virtual_handle_fault" TRACE msg were
added by me to show the code flow before the exception.

Thread 0x2f ought to fix the problem by "accidentally" resetting the write
watch also for code executed in thread 0x32.

Attached is a winedbg session showing the same problem.
Only threads 0x18 and 0x1B are of interest.
Thread 0x18 is actually zeroing GC heap memory at this point, causing the
fault.

I first thought about a race condition in fault handler while adjusting vm page
protection but multiple threads causing faults/page protection changes should
be serialized by "csVirtual" critical section.

Just to be sure, my Linux kernel:

--- snip ---
2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
--- snip ---

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.