https://bugs.winehq.org/show_bug.cgi?id=54889
Bug ID: 54889 Summary: shell32.dll compile with clang-16 on termux-x86 LLVM ERROR: out of memory Product: Wine Version: 8.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs@winehq.org Reporter: szl19921231@gmail.com Distribution: ---
Created attachment 74387 --> https://bugs.winehq.org/attachment.cgi?id=74387 compile error log
build i386 wine: winegcc output shell32.dll LLVM out of memory from wine-8.2, win-8.1 is ok
compile on termux-app_v0.118.0+github-debug_x86.apk clang-16.0.1 i686
but x86_64 wine can build shell32.dll ok on termux-app_v0.118.0debug_x86_64.apk
https://bugs.winehq.org/show_bug.cgi?id=54889
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
https://bugs.winehq.org/show_bug.cgi?id=54889
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- This is an llvm bug; please report it to the llvm project.
https://bugs.winehq.org/show_bug.cgi?id=54889
szl szl19921231@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|NOTOURBUG |---
--- Comment #2 from szl szl19921231@gmail.com --- The llvm-project developer said that it is not their bug, and suggested that the problem might be that the connection with shell32.dll exceeded the maximum memory that can be used by 32 bits (4GB). I think there is some truth to this, and moreover, the same clang version compiled without problems using shell32.dll on wine-8.1, while linking failed on wine-8.2. Could it be that version 8.2 modified some linking commands and caused a need for very large memory, which resulted in a memory overflow?
https://bugs.winehq.org/show_bug.cgi?id=54889
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- (In reply to szl from comment #2)
The llvm-project developer said that it is not their bug, and suggested that the problem might be that the connection with shell32.dll exceeded the maximum memory that can be used by 32 bits (4GB).
Can you perhaps link to this discussion?
LLVM is known to be far more memory hungry than binutils ld. I tested with ulimit -v, and binutils ld can link 32-bit shell32 with as few as 64 MiB of available virtual memory (though not much lower than that), which means that whether they want to or not, I think this is a bug they can theoretically fix.
If they don't want to, I suppose that's their right, but I don't think it should be the responsibility of Wine to accommodate that either, not without some hard evidence that there's something simple we can do to significantly lower memory usage.
I think there is some truth to this, and moreover, the same clang version compiled without problems using shell32.dll on wine-8.1, while linking failed on wine-8.2. Could it be that version 8.2 modified some linking commands and caused a need for very large memory, which resulted in a memory overflow?
Nothing of the sort was done. In fact, somewhat unusually, there were no modifications to shell32 or any part of the build system between 8.1 and 8.2. I don't know how to account for the difference in that case... best guess is that an import library changed just enough to break the camel's back?
https://bugs.winehq.org/show_bug.cgi?id=54889
--- Comment #4 from szl szl19921231@gmail.com --- I found that tools/winebuild/res32.c caused the problem, replaced 8.2 res32.c with 8.1 res32.c, compiled ok, I compared the changes, does xstrdup need free?, and commented "output( "t.incbin "%s",%d,%dn", res->input_name, res->input_offset, res-> data_size ); "This line, the compilation is also OK, I add an if(i%20)output(...) in front of this line, it can also be compiled through, so I feel that there is a memory leak, trouble to help see, I didn't locate the problem myself
https://bugs.winehq.org/show_bug.cgi?id=54889
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to szl from comment #4)
I found that tools/winebuild/res32.c caused the problem, replaced 8.2 res32.c with 8.1 res32.c, compiled ok, I compared the changes, does xstrdup need free?, and commented "output( "t.incbin "%s",%d,%dn", res->input_name, res->input_offset, res-> data_size ); "This line, the compilation is also OK, I add an if(i%20)output(...) in front of this line, it can also be compiled through, so I feel that there is a memory leak, trouble to help see, I didn't locate the problem myself
That might indicate that 0b3f90ab1485d5bd32bd72d41c7fd8213b3b95b9 is to blame: https://gitlab.winehq.org/wine/wine/-/commit/0b3f90ab1485d5bd32bd72d41c7fd82... Does reverting that commit help?
https://bugs.winehq.org/show_bug.cgi?id=54889
--- Comment #6 from szl szl19921231@gmail.com --- Yes, rollback this commit compiles fine
https://bugs.winehq.org/show_bug.cgi?id=54889
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com Status|UNCONFIRMED |NEW Regression SHA1| |0b3f90ab1485d5bd32bd72d41c7 | |fd8213b3b95b9 Keywords| |regression Ever confirmed|0 |1
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru --- Adding author of the patch to the cc: list.
https://bugs.winehq.org/show_bug.cgi?id=54889
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Regression SHA1|0b3f90ab1485d5bd32bd72d41c7 | |fd8213b3b95b9 | Status|NEW |RESOLVED Keywords|regression |
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- That's clearly an LLVM bug then. There's no reason for .incbin to eat more memory than the same data printed out as .long. My guess would be that it stores a full copy of the file for each .incbin instead of only the part that's needed.
https://bugs.winehq.org/show_bug.cgi?id=54889
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |randrik@mail.ru
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- *** Bug 55098 has been marked as a duplicate of this bug. ***