[Bug 59472] New: FreeArc hangs on startup in new wow64 mode
http://bugs.winehq.org/show_bug.cgi?id=59472 Bug ID: 59472 Summary: FreeArc hangs on startup in new wow64 mode Product: Wine Version: 11.3 Hardware: x86-64 URL: https://archive.org/details/FreeArc-0.666-win32bin-Sou rces OS: Linux Status: NEW Keywords: download, testcase, wow64 Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@list.winehq.org Reporter: arethusa26@gmail.com Distribution: --- Created attachment 80459 --> http://bugs.winehq.org/attachment.cgi?id=80459 Largest memory block loop test case executable When running the FreeArc archiver tool on the command line to add a file to an archive with a new wow64 build of Wine, the tool hangs indefinitely with only a banner output string: $ wine freearc/bin/Arc.exe a test.arc empty_file 0124:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION FreeArc 0.666 With a old wow64 build of Wine, the tool runs and completes successfully: $ wine freearc/bin/Arc.exe a test.arc empty_file 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION FreeArc 0.666 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 ... creating archive: test.arc Compressing 1 file, 1,024 bytes. Processed 0% 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 ... Compressed 1 file, 1,024 => 44 bytes. Ratio 4.2% Compression time: cpu 0.62 secs, real 0.31 secs. Speed 3 kB/s All OK To reproduce the issue with FreeArc, download "FreeArc-portable-0.666-win32.zip" from the URL link and extract the contents of the ZIP file to a directory named "freearc". The Arc.exe binary can be run with the provided command line. When FreeArc is run with new wow64 Wine, there appears to be a thread that is stuck repeatedly calling VirtualAlloc with 0 size: 0124:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 0124:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 0124:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 0124:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 The code involved in the hang appears to be the LargestMemoryBlock::LargestMemoryBlock() constructor in Environment.cpp from the FreeArc sources. It's a (buggy) loop that attempts a binary search for the largest size it can successfully pass to VirtualAlloc. I have extracted the logic to create a standalone test case, which is built with: i686-w64-mingw32-gcc -O2 -Wall -Wl,--large-address-aware -o largest_memory_block.exe largest_memory_block.c On Windows 10, the largest_memory_block.exe test case shows the following output: a = 0 b = ffffffff Freeing pointer 00000000 with VirtualFree Allocating 7fffffff bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 7fffffff a = 0 b = 7fffffff Freeing pointer 00000000 with VirtualFree Allocating 3fffffff bytes with VirtualAlloc VirtualAlloc returned 01970000 VirtualAlloc succeeded, updating a to 3fffffff ... a = 7f98ffff b = 7f990001 Freeing pointer 00000000 with VirtualFree Allocating 7f990000 bytes with VirtualAlloc VirtualAlloc returned 7fff0000 VirtualAlloc succeeded, updating a to 7f990000 On new wow64 Wine, the test case shows the following output: a = 0 b = ffffffff Freeing pointer 00000000 with VirtualFree Allocating 7fffffff bytes with VirtualAlloc VirtualAlloc returned 7fff0000 VirtualAlloc succeeded, updating a to 7fffffff a = 7fffffff b = ffffffff Freeing pointer 7fff0000 with VirtualFree Allocating 3fffffff bytes with VirtualAlloc VirtualAlloc returned 00900000 VirtualAlloc succeeded, updating a to 3fffffff ... a = 1 b = ffffffff Freeing pointer 003f0000 with VirtualFree Allocating 0 bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 0 a = 1 b = 0 Freeing pointer 00000000 with VirtualFree Allocating 0 bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 0 ... The midpoint computation "c = (a + b) / 2" in the loop overflows when the initial allocation succeeds on Wine and leads to incorrect execution, whereas the initial allocation doesn't appear to succeed on Windows. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 --- Comment #1 from Andrew Nguyen <arethusa26@gmail.com> --- Created attachment 80460 --> http://bugs.winehq.org/attachment.cgi?id=80460 Largest memory block loop test case source Compile the source file with i686-w64-mingw32-gcc -O2 -Wall -Wl,--large-address-aware -o largest_memory_block.exe largest_memory_block.c -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 LingM <lingm+winebz@posteo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lingm+winebz@posteo.org --- Comment #2 from LingM <lingm+winebz@posteo.org> --- Duplicate of bug 58698? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org --- Comment #3 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 80940 --> http://bugs.winehq.org/attachment.cgi?id=80940 test program, slightly different way to find out maximum allocation size In this testbot run [1] this test program shows the biggest single allocation was 0x7fe10000 bytes in size, and returned always pointers at address 0x7fff0000. Wine's wow64 returns also addresses at 0x7fff0000, but a maximum allocation size of 0x80010000. [1] https://testbot.winehq.org/JobDetails.pl?Key=162975 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 --- Comment #4 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 80941 --> http://bugs.winehq.org/attachment.cgi?id=80941 ntdll: Reserve last 68 kb of 32-bit address space in new wow64. This patch makes (at my system) Wine not return allocations greater or equal to 0x8000000. With it applied the largest_memory_block test program does return. This reservation most probably should already take place at some preloader stage? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 brandow <brandowlucas@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brandowlucas@gmail.com --- Comment #5 from brandow <brandowlucas@gmail.com> --- (In reply to Bernhard Übelacker from comment #4)
Created attachment 80941 [details] ntdll: Reserve last 68 kb of 32-bit address space in new wow64.
This patch makes (at my system) Wine not return allocations greater or equal to 0x8000000. With it applied the largest_memory_block test program does return.
This reservation most probably should already take place at some preloader stage? This patch also fixes a hang with new WoW64 in FitGirl Repack installers while decompressing FreeArc archives.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- (In reply to brandow from comment #5)
This patch also fixes a hang with new WoW64 in FitGirl Repack installers while decompressing FreeArc archives. Good to know. I've been using wine 10 as workaround in the meantime.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Alexandre Julliard <julliard@winehq.org> --- Duplicate. *** This bug has been marked as a duplicate of bug 58698 *** -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59472 Austin English <austinenglish@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Austin English <austinenglish@gmail.com> --- Closing. -- 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.
participants (1)
-
WineHQ Bugzilla