[Bug 17135] New: virtual write watches cause problems in multithreaded .NET code (simultaneous GC heap allocations)
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@winehq.org ReportedBy: focht@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@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
http://bugs.winehq.org/show_bug.cgi?id=17135
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet, download, Installer, | |regression
http://bugs.winehq.org/show_bug.cgi?id=17135
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2009-01-26 08:06:46 --- Created an attachment (id=19002) --> (http://bugs.winehq.org/attachment.cgi?id=19002) Ignore fault on writable watch page.
You could try something like this.
http://bugs.winehq.org/show_bug.cgi?id=17135
--- Comment #2 from Anastasius Focht focht@gmx.net 2009-01-26 14:32:45 --- Hello,
--- quote --- Ignore fault on writable watch page.
You could try something like this. --- quote ---
Yes, it fixes the problem. The test script executed unattended install 50 times in a row without any exception.
Interesting catch ;-)
Regards
http://bugs.winehq.org/show_bug.cgi?id=17135
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2009-01-27 11:04:07 --- AJ committed the fix today.
http://bugs.winehq.org/show_bug.cgi?id=17135
--- Comment #4 from Anastasius Focht focht@gmx.net 2009-01-27 14:20:05 --- Hello,
--- quote --- AJ committed the fix today. --- quote ---
Yes, I know. ;-) I prefer to have the corresponding commit id included for proper backtracking.
Fixed by commit 5e7f7db92386b2cd5109dd76948dff5a15ce1f31
Regards
http://bugs.winehq.org/show_bug.cgi?id=17135
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2009-01-30 11:05:16 --- Closing bugs fixed in 1.1.14.
http://bugs.winehq.org/show_bug.cgi?id=17135
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5e7f7db92386b2cd5109dd76948 | |dff5a15ce1f31 Regression SHA1| |af8bb2e9222a79cc6ef2fa22c4e | |ac75122eac5de
--- Comment #6 from Anastasius Focht focht@gmx.net 2011-10-12 03:10:53 CDT --- Hello,
filling/correcting fields ...
Regards
http://bugs.winehq.org/show_bug.cgi?id=17135
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86 OS|other |Linux
https://bugs.winehq.org/show_bug.cgi?id=17135
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.microsoft.com/do |https://web.archive.org/web |wnloads/details.aspx?Family |/20090202091626/http://down |ID=262d25e3-f589-4842-8157- |load.microsoft.com/download |034d1e7cf3a3&displaylang=en |/a/a/c/aac39226-8825-44ce-9 | |0e3-bf8203e74006/dotnetfx.e | |xe
-
wine-bugs＠winehq.org -
WineHQ Bugzilla