http://bugs.winehq.org/show_bug.cgi?id=14275
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net 2008-07-06 06:55:15 --- Hello,
the app tries to VirtualLock() a range of previously reserved memory which fails and leads to crash due to buggy application error handling.
This won't work for linux anyway because wine calls mlock() which requires root or user must be a member of a group that has the MLOCK privilege.
Neither Windows VirtualLock() nor Linux mlock() guarantee that the pages requested for locking are never paged out. In Windows, the only pages that never get paged out are those allocated from non-paged pool (which never applies to user processes until explicitly requested by using some AWE API).
They followed the Windows guideline of trimming the process working set through SetProcessWorkingSet() first before trying to lock the memory, which is required prerequisite.
Relevant trace:
--- snip trace --- 0050:Call KERNEL32.GlobalMemoryStatus(0032fad8) ret=0053b4c0 0050:Ret KERNEL32.GlobalMemoryStatus() retval=68edcfff ret=0053b4c0 0050:Call KERNEL32.GetCurrentProcess() ret=0053b5c6 0050:Ret KERNEL32.GetCurrentProcess() retval=ffffffff ret=0053b5c6 0050:Call KERNEL32.SetProcessWorkingSetSize(ffffffff,6aa15000,6ea15000) ret=0053b5cd 0050:Ret KERNEL32.SetProcessWorkingSetSize() retval=00000001 ret=0053b5cd 0050:Call KERNEL32.GetLastError() ret=0053b5df 0050:Ret KERNEL32.GetLastError() retval=00000000 ret=0053b5df .. 0050:Call KERNEL32.VirtualAlloc(00000000,00100010,00001000,00000004) ret=0053b729 0050:Ret KERNEL32.VirtualAlloc() retval=03e80000 ret=0053b729 0050:Call KERNEL32.VirtualLock(03e80000,00100010) ret=0053ac32 0050:Ret KERNEL32.VirtualLock() retval=00000000 ret=0053ac32 0050:Call KERNEL32.GetLastError() ret=0053ac41 0050:Ret KERNEL32.GetLastError() retval=00000005 ret=0053ac41 0050:Call KERNEL32.GetLastError() ret=009ddab3 0050:Ret KERNEL32.GetLastError() retval=00000005 ret=009ddab3 0050:Call KERNEL32.TlsGetValue(00000003) ret=009dd971 0050:Ret KERNEL32.TlsGetValue() retval=7b827efc ret=009dd971 0050:Call KERNEL32.FlsGetValue(00000000) ret=009ddac2 0050:Ret KERNEL32.FlsGetValue() retval=03d70118 ret=009ddac2 0050:Call KERNEL32.SetLastError(00000005) ret=009ddb1d 0050:Ret KERNEL32.SetLastError() retval=00000005 ret=009ddb1d .. 0050:trace:seh:raise_exception code=c0000005 flags=0 addr=0x4290e1 0050:trace:seh:raise_exception info[0]=00000000 0050:trace:seh:raise_exception info[1]=00000004 0050:trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000015 edx=00000000 esi=0032fa78 edi=03dad760 0050:trace:seh:raise_exception ebp=0032fa3c esp=0032fa38 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 0050:trace:seh:call_stack_handlers calling handler at 0xa28dd8 code=c0000005 flags=0 --- snip trace ---
I suggest that wine just pretends "success" to let such applications continue because the POSIX calls won't succeed anyway. The following hack lets the app successfully start. It ignores mlock/munlock errors, pretending success.
--- snip hack --- diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c index ef97eb2..8db0a32 100644 --- a/dlls/ntdll/virtual.c +++ b/dlls/ntdll/virtual.c @@ -1862,7 +1862,11 @@ NTSTATUS WINAPI NtLockVirtualMemory( HANDLE process, PVOID *addr, SIZE_T *size, *size = ROUND_SIZE( *addr, *size ); *addr = ROUND_ADDR( *addr, page_mask );
- if (mlock( *addr, *size )) status = STATUS_ACCESS_DENIED; + if (mlock( *addr, *size )) + { + WARN_(virtual)( "mlock() failed, pretending success\n"); + } + return status; }
@@ -1899,7 +1903,10 @@ NTSTATUS WINAPI NtUnlockVirtualMemory( HANDLE process, PVOID *addr, SIZE_T *size *size = ROUND_SIZE( *addr, *size ); *addr = ROUND_ADDR( *addr, page_mask );
- if (munlock( *addr, *size )) status = STATUS_ACCESS_DENIED; + if (munlock( *addr, *size )) + { + WARN_(virtual)( "munlock() failed, pretending success\n"); + } return status; } --- snip hack ---
Though the app's error handling remains questionable. I verified the demo crashes the same way in Windows when I simulated the error in the debugger.
Regards