http://bugs.winehq.org/show_bug.cgi?id=17277
Summary: Remote virtual memory allocation error Product: Wine Version: 1.1.13 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader AssignedTo: wine-bugs@winehq.org ReportedBy: gabmoa@yahoo.it
ZFlash is a win32 application used to simulate and edit part programs for a cnc. The simulator part is achieved running a reduced version of numerical control into a fixed memory map from 1 to 8 MB (the current version is from 1-16 MB but it's the same principle). The numerical control need to be mapped in this way because it uses fixed addresses. The application runs in NT 4 SP6, 2000, XP and Vista MS OS but in wine it doesn't work. I have seen there is a problem in the memory mapping when I try to run the application into wine so I've created a reduced example with the only "incriminated" part. In the attached zip file there are 3 projects: ZLoader, Z32Sim and Test. The steps involved are the same of the complete win32 application.
ZLoader.exe create the process 'Test', suspended, and try to reserve memory of 'Test' from 1 to 8 MB, then it resumes the process.
Test.exe is compiled with the linker flags /base:"0x800000" /stack:0x800000,0x1000 so the big stack can not be inserted into the first 8MB and the base of exe is changed from the default 4MB assigned by Visual Studio.
Z32Sim.dll is loaded into 'Test' and it have to map the memory (1-8MB).
To test it in the Debug directory we can execute ZLoader Test.exe In wine Test fail when ZLoader try to resume it (I've seen that with winedbg) with the following error:
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7ef9e617
Unfortunately it seems a not so easy task because with winedbg I can't attach to Test process when it's suspended.
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #1 from Gabriele Moabiti gabmoa@yahoo.it 2009-02-06 08:31:10 --- Created an attachment (id=19279) --> (http://bugs.winehq.org/attachment.cgi?id=19279) Visual studio test projects
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #2 from Austin English austinenglish@gmail.com 2009-08-13 13:10:48 --- Is this still an issue in current (1.1.27 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #3 from Gabriele Moabiti gabmoa@yahoo.it 2009-08-16 19:16:59 --- (In reply to comment #2)
Is this still an issue in current (1.1.27 or newer) wine?
yes, tested with 1.1.27
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2009-08-16 20:53:03 --- (In reply to comment #0)
Test.exe is compiled with the linker flags /base:"0x800000" /stack:0x800000,0x1000
That's your problem, put stack above. Wine needs lots of stack and it's not about to change any time soon if ever.
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2009-08-17 13:11:58 --- The stack shouldn't be an issue, but the process heap is allocated in the first 8Mb too, unmapping that probably has bad results...
http://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #6 from Gabriele Moabiti gabmoa@yahoo.it 2009-08-17 13:30:03 --- (In reply to comment #5)
The stack shouldn't be an issue, but the process heap is allocated in the first 8Mb too, unmapping that probably has bad results...
In windows it works... but the problem maybe is related to the different behaviour in wine when Test is created in suspend mode (CREATE_SUSPEND) by ZLoader ...
http://bugs.winehq.org/show_bug.cgi?id=17277
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
http://bugs.winehq.org/show_bug.cgi?id=17277
butraxz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |butraxz@gmail.com
--- Comment #7 from butraxz@gmail.com 2012-05-20 11:12:56 CDT --- This bug has not been updated for three years. Is this still an issue in current (1.5.4 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=17277
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Summary|Remote virtual memory |ZFlash numerical control |allocation error |app needs address space | |between 0x100000-0x800000 | |(1-8 MiB) which conflicts | |with process heap location Ever confirmed|0 |1
--- Comment #8 from Anastasius Focht focht@gmx.net --- Hello folks,
next time please attach precompiled *release* builds of the apps. Debug builds don't add any value. In fact they link to the debug versions of the MSVC++ runtime which are not (to be) distributed.
To illustrate what Alexandre said...
Parent process starting child process suspended and freeing up child address space:
--- snip --- $ wine ./ZLoader.exe test.exe fixme:heap:HeapSetInformation (nil) 1 (nil) 0 ZLoader - VirtualFreeEx BaseAddress: 00110000 - Size: 00010000 ZLoader - VirtualFreeEx BaseAddress: 00220000 - Size: 00001000 ZLoader - VirtualFreeEx BaseAddress: 00221000 - Size: 00001000 ZLoader - VirtualFreeEx BaseAddress: 00230000 - Size: 00003000 --- snip ---
Relevant part of trace log:
--- snip --- ... 0031:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 00110000 2000 00000004 0031:trace:virtual:map_view got mem in reserved area 0x110000-0x220000 0031:trace:virtual:VIRTUAL_DumpView View: 0x110000 - 0x21ffff (valloc) 0031:trace:virtual:VIRTUAL_DumpView 0x110000 - 0x21ffff --rw- 0031:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x110000 00010000 1000 00000004 0031:trace:virtual:VIRTUAL_SetProt 0x110000-0x11ffff c-rw- 0031:trace:virtual:VIRTUAL_DumpView View: 0x110000 - 0x21ffff (valloc) 0031:trace:virtual:VIRTUAL_DumpView 0x110000 - 0x11ffff c-rw- 0031:trace:virtual:VIRTUAL_DumpView 0x120000 - 0x21ffff --rw- 0031:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 0000065c 1000 00000004 0031:trace:virtual:map_view got mem in reserved area 0x220000-0x221000 0031:trace:virtual:VIRTUAL_DumpView View: 0x220000 - 0x220fff (valloc) 0031:trace:virtual:VIRTUAL_DumpView 0x220000 - 0x220fff c-rw- 0031:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 0000232c 1000 00000004 0031:trace:virtual:map_view got mem in reserved area 0x230000-0x233000 0031:trace:virtual:VIRTUAL_DumpView View: 0x230000 - 0x232fff (valloc) 0031:trace:virtual:VIRTUAL_DumpView 0x230000 - 0x232fff c-rw- 0031:trace:virtual:VIRTUAL_DumpView View: 0x7bc10000 - 0x7bceefff (system) 0031:trace:virtual:VIRTUAL_DumpView 0x7bc10000 - 0x7bceefff c-rWx 0031:trace:virtual:virtual_create_builtin_view created 0x7bc10000-0x7bcef000 ... 0031:Call KERNEL32.__wine_kernel_init() ret=7bc5a259 ... 002f:Call KERNEL32.VirtualFreeEx(0000004c,00110000,00000000,00008000) ret=004010a4 002f:Call ntdll.NtFreeVirtualMemory(0000004c,0033f954,0033f958,00008000) ret=7b882bb3 002f:trace:virtual:NtFreeVirtualMemory 0x4c 0x110000 00000000 8000 0031:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x110000 00000000 8000 002f:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b882bb3 ... 002f:Call KERNEL32.VirtualFreeEx(0000004c,00220000,00000000,00008000) ret=004010a4 002f:Call ntdll.NtFreeVirtualMemory(0000004c,0033f954,0033f958,00008000) ret=7b882bb3 002f:trace:virtual:NtFreeVirtualMemory 0x4c 0x220000 00000000 8000 0031:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x220000 00000000 8000 002f:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b882bb3 002f:Ret KERNEL32.VirtualFreeEx() retval=00000001 ret=004010a4 ... 002f:Call KERNEL32.VirtualFreeEx(0000004c,00221000,00000000,00008000) ret=004010a4 002f:Call ntdll.NtFreeVirtualMemory(0000004c,0033f954,0033f958,00008000) ret=7b882bb3 002f:trace:virtual:NtFreeVirtualMemory 0x4c 0x221000 00000000 8000 0031:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x221000 00000000 8000 002f:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b882bb3 002f:Ret KERNEL32.VirtualFreeEx() retval=00000001 ret=004010a4 ... 002f:Call KERNEL32.VirtualFreeEx(0000004c,00230000,00000000,00008000) ret=004010a4 002f:Call ntdll.NtFreeVirtualMemory(0000004c,0033f954,0033f958,00008000) ret=7b882bb3 002f:trace:virtual:NtFreeVirtualMemory 0x4c 0x230000 00000000 8000 0031:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x230000 00000000 8000 002f:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b882bb3 002f:Ret KERNEL32.VirtualFreeEx() retval=00000001 ret=004010a4 ... 002f:Call ntdll.NtAllocateVirtualMemory(0000004c,0033f914,00000000,0033f948,00002000,00000040) ret=7b882af9 002f:trace:virtual:NtAllocateVirtualMemory 0x4c 0x100000 00700000 2000 00000040 0031:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x100000 00700000 2000 00000040 0031:trace:virtual:VIRTUAL_DumpView View: 0x100000 - 0x7fffff (valloc) 0031:trace:virtual:VIRTUAL_DumpView 0x100000 - 0x7fffff --rwx 002f:Ret ntdll.NtAllocateVirtualMemory() retval=00000000 ret=7b882af9 002f:Ret KERNEL32.VirtualAllocEx() retval=00100000 ret=00401103 002f:Call user32.MessageBoxA(00000000,00408158 "ZLoader now will resume the thread",0040817c "ZLoader",00000040) ret=00401117 --- snip ---
Child process crash after the main thread is resumed by parent:
--- snip --- Unhandled exception: page fault on read access to 0x001106e4 in 32-bit code (0x7bc54d69). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc54d69 ESP:0100ff40 EBP:0100ffa8 EFLAGS:00010246( R- -- I Z- -P- ) EAX:001106b0 EBX:7bcd2000 ECX:0100ffb0 EDX:00000023 ESI:ffb1d7b4 EDI:00000000 Stack dump: 0x0100ff40: 00000000 ffffffff 0100ff58 7bc395a6 0x0100ff50: 7bcdaf28 00000001 0100ff98 7bc3a0aa 0x0100ff60: 7bcdaf28 00000000 00000000 00000000 0x0100ff70: 00000000 7ffd8000 00000000 00000000 0x0100ff80: 00000000 00000000 00000000 0100ffb0 0x0100ff90: 7bcd2000 ffb1d7b4 0100ffe8 00000000 000c: sel=0067 base=00000000 limit=00000000 16-bit r-x Backtrace: =>0 0x7bc54d69 process_attach+0x2e(wm=0x1106b0, lpReserved=0x1) [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/loader.c:1148] in ntdll<elf> (0x0100ffa8) 1 0x7bc594d9 attach_process_dlls+0x53(wm=0x1106b0) [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/loader.c:2799] in ntdll<elf> (0x0100ffe8) 2 0xf753ffb5 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 3 0x7bc59a3b LdrInitializeThunk+0x2ca(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/loader.c:2919] in ntdll<elf> (0xffb1d848) 4 0x7b8652cc __wine_kernel_init+0x67d() [/home/focht/projects/wine/wine.repo/src/dlls/kernel32/process.c:1276] in kernel32<elf> (0xffb1e708) 5 0x7bc5a259 __wine_process_init+0x156() [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/loader.c:3133] in ntdll<elf> (0xffb1e768) 6 0xf753e825 wine_init+0x140(argc=0x2, argv=0xffb1ec74, error="", error_size=0x400) [/home/focht/projects/wine/wine.repo/src/libs/wine/loader.c:958] in libwine.so.1 (0xffb1e7a8) 7 0x7bf011ae main+0x132(argc=0x2, argv=0xffb1ec74) [/home/focht/projects/wine/wine.repo/src/loader/main.c:237] in <wine-loader> (0xffb1ebd8) 8 0xf734e963 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7bc54d69 process_attach+0x2e [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/loader.c:1148] in ntdll<elf>: movl 0x34(%eax),%eax 1148 if ( ( wm->ldr.Flags & LDR_LOAD_IN_PROGRESS ) --- snip ---
This obviously can't work.
Changing/relocating the process heap because there is one app depending on this is questionable.
Anyway, you can change this on your own, making the app work:
http://source.winehq.org/git/wine.git/blob/34b2d920b47122007b65d435e064d018f...
If Alexandre says he doesn't want that change, the bug is essentially a WONTFIX.
Regards
https://bugs.winehq.org/show_bug.cgi?id=17277
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=17277
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=38432 CC| |nerv@dawncrow.de
--- Comment #9 from André H. nerv@dawncrow.de --- Does it work in recent Wine versions, because a related bug seems fixed (See Also) Or is this abandoned meanwhile?
https://bugs.winehq.org/show_bug.cgi?id=17277
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.winehq.org/sho | |w_bug.cgi?id=38432 |
https://bugs.winehq.org/show_bug.cgi?id=17277
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Keywords| |source
https://bugs.winehq.org/show_bug.cgi?id=17277
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello André,
--- quote --- Does it work in recent Wine versions, because a related bug seems fixed (See Also) Or is this abandoned meanwhile? --- quote ---
No, nothing has changed with regards to default process heap location. The test app still crashes as expected.
Proof:
--- snip --- $ WINEDEBUG=+pid,+seh,+loaddll,+process,+relay,+module wine ./ZLoader.exe test.exe >>log.txt 2>&1
... 0020:0024:Call ntdll.NtCreateUserProcess(0021f828,0021f82c,001fffff,001fffff,0021f6ac,0021f694,00000200,00000001,00472320,0021f748,0021f6c4) ret=7b038367 ... 0104:0108:trace:module:map_image_into_view mapping PE file L"\??\Z:\home\focht\Downloads\z\Test.exe" at 0x800000-0x818000 ... 0104:0108:trace:module:map_image_into_view mapping PE file L"\??\C:\windows\system32\ntdll.dll" at 0x7bc00000-0x7bc80000 ... 0020:0024:trace:process:NtCreateUserProcess L"\??\Z:\home\focht\Downloads\z\Test.exe" pid 0104 tid 0108 handles 0x6c/0x70 0020:0024:Ret ntdll.NtCreateUserProcess() retval=00000000 ret=7b038367 ... 0020:0024:trace:process:CreateProcessInternalW started process pid 0104 tid 0108 ... 0020:0024:Ret KERNEL32.CreateProcessA() retval=00000001 ret=00401188 0020:0024:Call KERNEL32.VirtualQueryEx(0000006c,00030000,0021fe60,0000001c) ret=00401228 0020:0024:Call ntdll.NtQueryVirtualMemory(0000006c,00030000,00000000,0021fe60,0000001c,0021f9b0) ret=7b02a0ef 0020:0024:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b02a0ef 0020:0024:Ret KERNEL32.VirtualQueryEx() retval=0000001c ret=00401228 0020:0024:Call KERNEL32.VirtualQueryEx(0000006c,00110000,0021fe60,0000001c) ret=00401228 0020:0024:Call ntdll.NtQueryVirtualMemory(0000006c,00110000,00000000,0021fe60,0000001c,0021f9b0) ret=7b02a0ef 0020:0024:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b02a0ef 0020:0024:Ret KERNEL32.VirtualQueryEx() retval=0000001c ret=00401228 0020:0024:Call KERNEL32.VirtualFreeEx(0000006c,00110000,00000000,00008000) ret=00401258 0020:0024:Call ntdll.NtFreeVirtualMemory(0000006c,0021f9c4,0021f9c8,00008000) ret=7b029f8b 0020:0024:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b029f8b 0020:0024:Ret KERNEL32.VirtualFreeEx() retval=00000001 ret=00401258 0020:0024:Call ntdll.RtlAllocateHeap(00cd0000,00000000,00001030) ret=00406d12 0020:0024:Ret ntdll.RtlAllocateHeap() retval=00cd0c48 ret=00406d12 0020:0024:Call KERNEL32.VirtualQueryEx(0000006c,00114000,0021fe60,0000001c) ret=00401228 0020:0024:Call ntdll.NtQueryVirtualMemory(0000006c,00114000,00000000,0021fe60,0000001c,0021f9b0) ret=7b02a0ef 0020:0024:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b02a0ef 0020:0024:Ret KERNEL32.VirtualQueryEx() retval=0000001c ret=00401228 0020:0024:Call KERNEL32.VirtualQueryEx(0000006c,00120000,0021fe60,0000001c) ret=00401228 0020:0024:Call ntdll.NtQueryVirtualMemory(0000006c,00120000,00000000,0021fe60,0000001c,0021f9b0) ret=7b02a0ef 0020:0024:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b02a0ef 0020:0024:Ret KERNEL32.VirtualQueryEx() retval=0000001c ret=00401228 0020:0024:Call KERNEL32.VirtualFreeEx(0000006c,00120000,00000000,00008000) ret=00401258 0020:0024:Call ntdll.NtFreeVirtualMemory(0000006c,0021f9c4,0021f9c8,00008000) ret=7b029f8b 0020:0024:Ret ntdll.NtFreeVirtualMemory() retval=00000000 ret=7b029f8b 0020:0024:Ret KERNEL32.VirtualFreeEx() retval=00000001 ret=00401258 0020:0024:Call KERNEL32.VirtualQueryEx(0000006c,00121000,0021fe60,0000001c) ret=00401228 0020:0024:Call ntdll.NtQueryVirtualMemory(0000006c,00121000,00000000,0021fe60,0000001c,0021f9b0) ret=7b02a0ef 0020:0024:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b02a0ef 0020:0024:Ret KERNEL32.VirtualQueryEx() retval=0000001c ret=00401228 0020:0024:Call KERNEL32.VirtualAllocEx(0000006c,00100000,00700000,00002000,00000040) ret=004012ba 0020:0024:Call ntdll.NtAllocateVirtualMemory(0000006c,0021f9ac,00000000,0021f9c8,00002000,00000040) ret=7b029dda 0020:0024:Ret ntdll.NtAllocateVirtualMemory() retval=00000000 ret=7b029dda 0020:0024:Ret KERNEL32.VirtualAllocEx() retval=00100000 ret=004012ba 0020:0024:Call user32.MessageBoxA(00000000,00422094 "ZLoader now will resume the thread",0042203c "ZLoader",00000040) ret=004012d7 ... 0020:0024:Ret user32.MessageBoxA() retval=00000001 ret=004012d7 0020:0024:Call KERNEL32.ResumeThread(00000070) ret=004010b2 0020:0024:Call ntdll.NtResumeThread(00000070,0021fe44) ret=7b04c713 0020:0024:Ret ntdll.NtResumeThread() retval=00000000 ret=7b04c713 0020:0024:Ret KERNEL32.ResumeThread() retval=00000001 ret=004010b2 0020:0024:Call KERNEL32.CloseHandle(00000070) ret=004010c8 0020:0024:Call ntdll.NtClose(00000070) ret=7b036f50 ... 0104:0108:trace:seh:dispatch_exception code=c0000005 flags=0 addr=7BC20290 ip=7bc20290 tid=0108 0104:0108:trace:seh:dispatch_exception info[0]=00000000 0104:0108:trace:seh:dispatch_exception info[1]=00110290 0104:0108:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised 0104:0108:trace:seh:dispatch_exception eax=7ffd1000 ebx=7ffd1000 ecx=00000002 edx=7ffd1044 esi=7ffd1000 edi=00110000 0104:0108:trace:seh:dispatch_exception ebp=0101ef18 esp=0101eccc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 0104:0108:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x7bc20290 ... 0020:0024:Call user32.MessageBoxA(00000000,0042201c "ZLoader will end",0042203c "ZLoader",00000040) ret=004010fa --- snip ---
Crash location in debuggee:
--- snip --- <ntdll._init_user_process_params>:
7BC20270 | push ebp | 7BC20271 | mov ebp,esp | 7BC20273 | push ebx | 7BC20274 | push edi | 7BC20275 | push esi | 7BC20276 | sub esp,240 | 7BC2027C | mov eax,dword ptr fs:[18] | ntdll/env.c:638 7BC20282 | mov dword ptr ss:[ebp-14],eax | 7BC20285 | mov eax,dword ptr ds:[eax+30] | ntdll/env.c:638 7BC20288 | mov ecx,2 | 7BC2028D | mov edi,dword ptr ds:[eax+10] | params 0x110000 7BC20290 | mov ebx,dword ptr ds:[edi+290] | ntdll/env.c:642 -> *boom* 7BC20296 | cmp ebx,2 | ntdll/env.c:643 7BC20299 | cmova ecx,ebx | 7BC2029C | push ecx | 7BC2029D | push 0 | 7BC2029F | push dword ptr ds:[eax+18] | 7BC202A2 | call ntdll._RtlAllocateHeap@12 | ... --- snip ---
Corresponding source:
https://source.winehq.org/git/wine.git/blob/9561af9a7d8d77e2f98341e278c84222...
--- snip --- 629 /*********************************************************************** 630 * init_user_process_params 631 * 632 * Fill the initial RTL_USER_PROCESS_PARAMETERS structure from the server. 633 */ 634 void init_user_process_params(void) 635 { 636 WCHAR *env; 637 SIZE_T env_size; 638 RTL_USER_PROCESS_PARAMETERS *new_params, *params = NtCurrentTeb()->Peb->ProcessParameters; 639 UNICODE_STRING curdir; 640 641 /* environment needs to be a separate memory block */ 642 env_size = params->EnvironmentSize; 643 if ((env = RtlAllocateHeap( GetProcessHeap(), 0, max( env_size, sizeof(WCHAR) )))) 644 { 645 if (env_size) memcpy( env, params->Environment, env_size ); 646 else env[0] = 0; 647 } --- snip ---
https://source.winehq.org/git/wine.git/blob/9561af9a7d8d77e2f98341e278c84222...
$ wine --version wine-6.9
Regards
https://bugs.winehq.org/show_bug.cgi?id=17277
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|fgouget@codeweavers.com |
-
wine-bugs＠winehq.org -
WineHQ Bugzilla