[Bug 50824] New: ISdone.dll error 5, something releated to insufficient virtual memory
https://bugs.winehq.org/show_bug.cgi?id=50824 Bug ID: 50824 Summary: ISdone.dll error 5, something releated to insufficient virtual memory Product: Wine Version: 6.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gab.pulcio(a)gmail.com Distribution: --- Created attachment 69642 --> https://bugs.winehq.org/attachment.cgi?id=69642 WINEDEBUG loaddll Warning: I know I'm about to ask you to fix something releated to game repacks, which they're illegal (provided I don't have the legal copy) but in my logic, that's a windows releated-thing and it should be fixed, maybe not now, but at least should be considered. Now, fitgirl repacks crashes at random progress, while rg-mechanics repacks are straight to the error, the same as always. I read that in the past this was fixed so that's a regression but since no-one has reported this and apparently no one has that problem, I'm filing this bug as normal. For the record: this bug happens since I installed linux, at the time Wine was at version 6.0. In my case, this repack is of a game that I legally own (Far Cry 3: Blood Dragon) but I've got a capped data plan and I have to install a repack then I'll be able to verify the game with Uplay. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 --- Comment #1 from Gabriele <gab.pulcio(a)gmail.com> --- Created attachment 69643 --> https://bugs.winehq.org/attachment.cgi?id=69643 WINEDEBUG seh -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 --- Comment #2 from Gabriele <gab.pulcio(a)gmail.com> --- Created attachment 69644 --> https://bugs.winehq.org/attachment.cgi?id=69644 Error -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 Gabriele <gab.pulcio(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |-unknown Version|6.4 |6.5 Product|Wine |Wine-staging CC| |leslie_alistair(a)hotmail.com | |, z.figura12(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 Gabriele <gab.pulcio(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|6.5 |6.15 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=50824 --- Comment #3 from Gabriele <gab.pulcio(a)gmail.com> --- Any clue? -- 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=50824 --- Comment #4 from Andrew Nguyen <arethusa26@gmail.com> --- Does the issue persist with the latest version of Wine? The particular crash you are observing may not be an issue anymore. -- 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=50824 --- Comment #5 from Fabian Maurer <dark.shadow4@web.de> --- FWIW, I think this is related to https://bugs.winehq.org/show_bug.cgi?id=48172, seems to be unable to allocate enough memory. Unless this is not a 32bit program... -- 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=50824 brandow <brandowlucas@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brandowlucas@gmail.com --- Comment #6 from brandow <brandowlucas@gmail.com> --- (In reply to Andrew Nguyen from comment #4)
Does the issue persist with the latest version of Wine? The particular crash you are observing may not be an issue anymore.
Yes, the installer usually fails during the unpacking phase with a return code -1 (Archive data corrupted). This is consistently triggered by repacks utilizing heavy Unarc compression (LZMA2). Observed Symptoms: GUI Error: ISDone.dll popup reporting "archive data corrupted (decompression fails)". Terminal Logs: High-frequency spam of memory allocation failures: err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size [hex_value] From what I gathered in dlls/ntdll/unix/virtual.c: The decompression process exhausts the 32-bit virtual address space (fragmentation or hitting the ~2-3 GB ceiling), causing NtAllocateVirtualMemory to return STATUS_NO_MEMORY. Unarc.dll's worker thread fails to allocate its decompression buffer and crashes, misreporting this as a corrupted archive rather than an out-of-memory condition. This issue is reproducible using wine git master both with new or old WOW64. -- 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=50824 --- Comment #7 from Gabriele <gab.pulcio@gmail.com> ---
This issue is reproducible using wine git master both with new or old WOW64.
Actually, using WOW64 makes the installer unable to progress... it gets silently stuck. -- 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=50824 Federico Dossena <info@fdossena.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |info@fdossena.com --- Comment #8 from Federico Dossena <info@fdossena.com> --- Created attachment 81058 --> http://bugs.winehq.org/attachment.cgi?id=81058 Workaround -- 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=50824 --- Comment #9 from Federico Dossena <info@fdossena.com> --- I had AI take a look at it and after half a day it found the cause and a potential workaround. The issue is caused by unarc doing something really silly: a binary search to find the largest VirtualAlloc that doesn't fail, starting with a 2GB that normally fails on windows (and on 32 bit wine), but for some reason succeeds on wow64 wine, causing an overflow inside unarc. The "fix" is the attached workaround, which simply makes all allocations requests >=2GB fail for 32 bit applications. -- 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=50824 --- Comment #10 from brandow <brandowlucas@gmail.com> --- (In reply to Federico Dossena from comment #9)
I had AI take a look at it and after half a day it found the cause and a potential workaround.
The issue is caused by unarc doing something really silly: a binary search to find the largest VirtualAlloc that doesn't fail, starting with a 2GB that normally fails on windows (and on 32 bit wine), but for some reason succeeds on wow64 wine, causing an overflow inside unarc.
The "fix" is the attached workaround, which simply makes all allocations requests >=2GB fail for 32 bit applications.
Hi Federico. It looks like this patch successfully got us past the new WoW64 hang at 0%, but the original unarc/freearc decompression failure is still cutting things short mid-way through the install. From what I could piece together so far during my debugging sessions last month, the whole issue feels like a massive communication breakdown between the main installer and the extraction tool. I'm somewhat new to this level of deep debugging, so I might be reading the signs all wrong, but here is my best guess based on what I saw. At first, I thought it was just a simple null-pointer bug caused by Wine feeding a "zero CPU core count" to the 64-bit decoder (pzlib.exe). Deeper crash logs seemed to blow past that theory, though. Instead, they revealed a wave of memory access violations right inside pzlib. It looks like after processing tens of megabytes of data, the tool's internal structures, coding tables, and thread locks just completely unravel and get corrupted. Forcing a single CPU thread or aggressively cutting down memory limits didn't seem to do a thing to stop it. If I had to bet on a root technical cause, it feels like an issue with how Wine handles data pipes, file markers, or the awkward dance of a 32-bit installer spawning a 64-bit child process. Right when the setup blows up, the main installer throws the CRC unarc checksum error and completely throws in the towel. Meanwhile, the pzlib decoder is left totally frozen in the background, just waiting forever on a host read syscall for data that's never going to arrive. This timing mismatch makes me wonder if Wine is accidentally breaking the data flow synchronization across the pipeline, or maybe scrambling how the data is laid out in memory. Lastly, something in this environment seems to trip a fatal memory corruption flaw unique to how pzlib handles streams, but I'd love a more experienced set of eyes to double check if my direction even makes sense. References: https://encode.su/threads/2506-pZLib https://github.com/zianke/pzlib -- 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 (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla