No subject


Tue Sep 2 11:01:37 CDT 2008 

--- snip ---
...
006e:Call KERNEL32.VirtualAlloc(00000000,02000000,00202000,00000004)
ret=79e74a2b
006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 02000000 202000
00000004
006e:trace:virtual:map_view got mem in reserved area 0x800000-0x2800000
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x27fffff --rw-
006e:Ret  KERNEL32.VirtualAlloc() retval=00800000 ret=79e74a2b
006e:Call KERNEL32.VirtualAlloc(00000000,000a0000,00203000,00000004)
ret=79e74a2b
...
--- snip ---

At startup, the .NET runtime reserves a large chunk of uncommitted memory, with
write watch set (MEM_RESERVE|MEM_WRITE_WATCH), protection attribute
PAGE_READWRITE. 

This is the heap the .NET runtime will work on.
After initialization phase, subsequent chunks from this reserved .NET heap get
committed to be used from managed code:

(alloc type MEM_COMMIT and protection PAGE_READWRITE)

--- snip ---
...
006e:Call KERNEL32.VirtualAlloc(01800000,00002000,00001000,00000004)
ret=79e74a2b
006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x1800000 00002000 1000
00000004
006e:trace:virtual:VIRTUAL_SetProt 0x1800000-0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x801000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1802000 - 0x27fffff --rw-
006e:Ret  KERNEL32.VirtualAlloc() retval=01800000 ret=79e74a2b
006e:trace:virtual:VIRTUAL_SetProt 0x1800000-0x1800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x801000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1801000 - 0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1802000 - 0x27fffff --rw-
006e:trace:virtual:VIRTUAL_SetProt 0x801000-0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1801000 - 0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1802000 - 0x27fffff --rw-
006e:trace:virtual:VIRTUAL_SetProt 0x1801000-0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1802000 - 0x27fffff --rw- 
...
006e:Call KERNEL32.VirtualAlloc(01802000,00010000,00001000,00000004)
ret=79e74a2b
006e:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x1802000 00010000 1000
00000004
006e:trace:virtual:VIRTUAL_SetProt 0x1802000-0x1811fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1802000 - 0x1811fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1812000 - 0x27fffff --rw-
006e:Ret  KERNEL32.VirtualAlloc() retval=01802000 ret=79e74a2b
006e:trace:virtual:VIRTUAL_SetProt 0x2850000-0x2850fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x2800000 - 0x289ffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x2800000 - 0x2800fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x2801000 - 0x284ffff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x2850000 - 0x2850fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x2851000 - 0x289ffff c-rw-
006e:trace:virtual:VIRTUAL_SetProt 0x1802000-0x1802fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView View: 0x800000 - 0x27fffff (valloc)
006e:trace:virtual:VIRTUAL_DumpView       0x800000 - 0x801fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x802000 - 0x17fffff --rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1800000 - 0x1802fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1803000 - 0x1811fff c-rw-
006e:trace:virtual:VIRTUAL_DumpView       0x1812000 - 0x27fffff --rw- 
...
01812000,0006a000 chunk covered by (1) trace
...
--- snip ---

Grmbl ... never trust Wine's virtual views alone - lets get heavier weapons ;-)

Dumping Linux kernel /proc/<pid>/maps relevant data...

After the first large chunk reserve
VirtualAlloc(00000000,02000000,00202000,00000004): 

--- snip ---
...
007bb000-02800000 ---p 007bb000 00:00 0
...
--- snip ---

Number of chunk commits following ...
Immediately before the last commit, with Wine's virtual views and proc maps
already inconsistent:

--- snip ---
...
00800000-008fe000 rw-p 00800000 00:00 0
008fe000-00902000 r--p 008fe000 00:00 0
00902000-01800000 ---p 00902000 00:00 0
01800000-01809000 rw-p 01800000 00:00 0
01809000-01812000 r--p 01809000 00:00 0
01812000-02800000 ---p 01812000 00:00 0
...
--- snip ---

After last commit, see (1), before failing ReadFile():

--- snip ---
...
00800000-008fe000 rw-p 00800000 00:00 0 
008fe000-00902000 r--p 008fe000 00:00 0                                        
00902000-01800000 ---p 00902000 00:00 0                                    
01800000-01809000 rw-p 01800000 00:00 0                                     
01809000-0187c000 r--p 01809000 00:00 0                                
0187c000-02800000 ---p 0187c000 00:00 0
...
--- snip ---

The problem is most likely dlls/ntdll/virtual.c:VIRTUAL_SetProt() which adjusts
page protection for individual pages when write watch is present.
For quick proof, comment out the code block in which handles VPROT_WRITEWATCH
for individual pages, falling back to original behaviour.
That should get .NET apps running again which suffer from resource loader
failures.

There are several other bugs with the installer, don't bother with them here.

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.

More information about the wine-bugs mailing list