[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.
http://bugs.winehq.org/show_bug.cgi?id=50824 --- Comment #11 from Gabriele <gab.pulcio@gmail.com> --- I am actually baffled (positively) there has been progress about this... didn't expect this at all, since we're talking about game repacks and it's randomly treated as it's this huge crime, even if done for legitimate reasons. I guess I didn't think about intelligent people (happy few), since my experiences with this topic were very bad. Anyway, let's make this useful. I have an habit of installing repacks first, then downloading the legal game and checking files (some games have terrible compression), this happens even if I own the game but don't download it because the game has more problem with the legal version than without. I saw huge improvements, a lot of repacks now installs with WOW64 mode, which is HUGE, and they don't get stuck at 0% anymore. Though, now I have a Ryzen 7 5800x and it's almost on idle when unpacking, something that shouldn't happen with FitGirl Repacks. DODI Repacks are a bit less aggressive, faster, and they can almost max the CPU, maybe different versions of unarc are used? I think it's a wine bug too, could be related to the memory issues? -- 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 #12 from Gabriele <gab.pulcio@gmail.com> --- (In reply to Gabriele from comment #11)
I saw huge improvements, a lot of repacks now installs with WOW64 mode, which is HUGE, and they don't get stuck at 0% anymore.
Damn, I forgot to tell: I'm using a gentoo system with multilib, yet no 32-bit libs/deps if possible, WINE compiled exclusively with 64-bit and no X, thus winewayland.drv and WOW64 is required for me. Wine-staging compiled from source, with -O3 -march=native -mtune=native (of course). I can disable WOW64 if problems arise, and still have a semblance of working wine, but it's rare, plus WOW64 works very very well now and I don't deem it problematic. -- 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 #13 from brandow <brandowlucas@gmail.com> --- After some reconsideration, I realized that the issue in my last message is a different unarc problem: `Does not match checksum! return code -12 CRC check failed`, rather than OP’s reported bug: `Not enough Memory! Unarc.dll returned an error code: -5`. As for my own bug (unrelated to memory), I found the root cause and will open a separate, proper bug report next week or so, when I have time. The new WoW64 0% hang, which affected both OP’s repack and my repack, is fixed by using Federico Dossena’s patch. For testing purposes, I tried OP’s *Far Cry 3: Blood Dragon* v1.05/v1.02 repack: `md5sum: 340af07f49b0330bd33ea80ed9ec2a80 setup.exe` I tested it with the 2 GB limit checkbox both enabled and disabled, using 7 GB of RAM and 8 GB of swap, and I could not reproduce the reported bug on Wine 11.12 using the new WoW64 mode with Federico’s WoW64 patch. That said, I think this patch should be considered a workaround rather than a proper fix. Ideally, Wine should address the underlying WoW64 virtual memory behavior that leads to these allocation failures, so new WoW64 behaves closer to a real 32-bit Windows environment in this case. Since fitgirl repacks also uses freearc/pzlib, this bug might also be related to https://bugs.winehq.org/show_bug.cgi?id=59472.
Though, now I have a Ryzen 7 5800X and it’s almost idle when unpacking, which should not happen with FitGirl Repacks.
Fitgirl repacks itself takes a lot of time due to high compression ratio (LZMA2/SREP). If this is something you cannot reproduce on Windows, I think it would be better to open a separate bug report for it. -- 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 #14 from brandow <brandowlucas@gmail.com> --- The following patch from bug 59472 also fixes the new WoW64 hang in my case: https://bugs.winehq.org/attachment.cgi?id=80941&action=diff&collapsed=&heade... As I mentioned in my previous comment, I can no longer reproduce the originally reported bug with the latest Wine Git master. Therefore, I believe this bug can be considered fixed. The new WoW64 hang appears to be a separate FreeArc issue and should be tracked under bug 59472 instead. -- 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 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Component|-unknown |-unknown Product|Wine-staging |Wine Status|UNCONFIRMED |RESOLVED --- Comment #15 from Ken Sharp <imwellcushtymelike@gmail.com> --- Marking fixed. Reopen if you can recreate this bug with the latest release of Wine. -- 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 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #16 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.16. -- 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