[Bug 50257] New: Regression: startup crash/infinite loop on FreeBSD
https://bugs.winehq.org/show_bug.cgi?id=50257 Bug ID: 50257 Summary: Regression: startup crash/infinite loop on FreeBSD Product: Wine Version: 6.0-rc1 Hardware: x86-64 OS: FreeBSD Status: NEW Severity: blocker Priority: P2 Component: msvcrt Assignee: wine-bugs(a)winehq.org Reporter: damjan.jov(a)gmail.com Lots of: 01ac:err:heap:HEAP_GetPtr Invalid heap 00000000! 01ac:err:heap:HEAP_GetPtr Invalid heap 00000000! Endless 100% CPU usage or crash. -- 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=50257 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |piotr(a)codeweavers.com Regression SHA1| |d784dbb89993d0565ea132109b1 | |10cc9500c97f4 --- Comment #1 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- Regression during beta release -> BLOCKER. Bisection result: d784dbb89993d0565ea132109b110cc9500c97f4 is the first bad commit commit d784dbb89993d0565ea132109b110cc9500c97f4 Author: Piotr Caban <piotr(a)codeweavers.com> Date: Tue Dec 1 13:51:32 2020 +0100 msvcrt: Remove MSVCRT_ prefix from heap.c functions. Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/crtdll/crtdll.spec | 20 ++--- dlls/msvcr100/msvcr100.spec | 58 +++++++-------- dlls/msvcr110/msvcr110.spec | 58 +++++++-------- dlls/msvcr120/msvcr120.spec | 58 +++++++-------- dlls/msvcr70/msvcr70.spec | 38 +++++----- dlls/msvcr71/msvcr71.spec | 38 +++++----- dlls/msvcr80/msvcr80.spec | 60 +++++++-------- dlls/msvcr90/msvcr90.spec | 58 +++++++-------- dlls/msvcrt/console.c | 4 +- dlls/msvcrt/cpp.c | 44 +++++------ dlls/msvcrt/data.c | 6 +- dlls/msvcrt/dir.c | 12 +-- dlls/msvcrt/environ.c | 4 +- dlls/msvcrt/errno.c | 14 ++-- dlls/msvcrt/except.c | 2 +- dlls/msvcrt/exit.c | 8 +- dlls/msvcrt/file.c | 56 +++++++------- dlls/msvcrt/heap.c | 56 +++++++------- dlls/msvcrt/locale.c | 174 ++++++++++++++++++++++---------------------- dlls/msvcrt/main.c | 16 ++-- dlls/msvcrt/math.c | 8 +- dlls/msvcrt/mbcs.c | 8 +- dlls/msvcrt/msvcrt.h | 12 +-- dlls/msvcrt/msvcrt.spec | 52 ++++++------- dlls/msvcrt/process.c | 104 +++++++++++++------------- dlls/msvcrt/scheduler.c | 46 ++++++------ dlls/msvcrt/string.c | 2 +- dlls/msvcrt/thread.c | 8 +- dlls/msvcrt/time.c | 24 +++--- dlls/msvcrt/wcs.c | 2 +- dlls/msvcrtd/msvcrtd.spec | 42 +++++------ dlls/ucrtbase/ucrtbase.spec | 38 +++++----- 32 files changed, 562 insertions(+), 568 deletions(-) -- 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=50257 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald(a)pfeifer.com, | |iwtcex(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=50257 --- Comment #2 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- This only affects the ELF build, the PE build starts up fine. Unfortunately mingw-w64 is still a work-in-progress on FreeBSD, so we use the ELF build exclusively. -- 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=50257 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #3 from Piotr Caban <piotr.caban(a)gmail.com> --- What compiler did you use? -- 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=50257 --- Comment #4 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Piotr Caban from comment #3)
What compiler did you use?
GCC 9.3.0 for the broken ELF build, along with mingw-w64's GCC 10.2.0 for the working PE build. -- 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=50257 --- Comment #5 from Piotr Caban <piotr.caban(a)gmail.com> --- I have verified that it works with GCC 9.3.0 on Linux (both 32 and 64-bit build). Could you please attach configure.log? Are there any warnings during compilation (maybe it will be easier if compilation output is also attached)? I have also tried compiling 64-bit wine on FreeBSD. I didn't dig into it but I'm getting: wine: could not load ntdll.so: (null) both with and without "msvcrt: Remove MSVCRT_ prefix from heap.c functions" patch. -- 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=50257 Alexander Vereeken <Alexander88207(a)Protonmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexander88207(a)Protonmail.c | |om -- 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=50257 Gen Otsuji <otsugen0000(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |otsugen0000(a)gmail.com --- Comment #6 from Gen Otsuji <otsugen0000(a)gmail.com> --- Hi, all. --------------------------------------- #include <stdio.h> #include <malloc.h> void * malloc(size_t size){ putchar('A'); return NULL; } int main(void){ char *p=malloc(20); return 0; } --------------------------------------- This code gets segfault on FreeBSD 12.2R. this bug has similar issue I think. -- 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=50257 --- Comment #7 from Gen Otsuji <otsugen0000(a)gmail.com> --- (In reply to Gen Otsuji from comment #6) I used both gcc9 and gcc10 and segfault occur. -- 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=50257 --- Comment #8 from Gen Otsuji <otsugen0000(a)gmail.com> --- I don't know whether Comment6's code compiled on Linux runs normally or not. -- 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=50257 --- Comment #9 from Gen Otsuji <otsugen0000(a)gmail.com> --- So, if on Linux it gets segfault the same way, I 'm sorry. Just I found it on FreeBSD. -- 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=50257 --- Comment #10 from Gerald Pfeifer <gerald(a)pfeifer.com> --- (In reply to Gen Otsuji from comment #9)
So, if on Linux it gets segfault the same way, I 'm sorry. Just I found it on FreeBSD.
Yes, openSUSE Tumbleweed with GCC 10.2.1 segfaults your example as well, Gen. (I'm not sure how this is related to the issue at hand.) -- 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=50257 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Gen Otsuji from comment #6)
Hi, all.
--------------------------------------- #include <stdio.h> #include <malloc.h> void * malloc(size_t size){ putchar('A'); return NULL; } int main(void){ char *p=malloc(20); return 0; } --------------------------------------- This code gets segfault on FreeBSD 12.2R. this bug has similar issue I think.
FWIW this example segfaults on Linux when compiled and run natively with no Wine involved:
gcc ./test.c -o test ./test Segmentation fault (core dumped)
-- 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=50257 --- Comment #12 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Gerald Pfeifer from comment #10)
Gen. (I'm not sure how this is related to the issue at hand.)
The crash is in the msvcrt DLLs, which export symbols with names similar to libc's symbols, just like that example code. ELF's symbol handling is generally a nightmare, as symbols are always global instead of library-scoped (like on Windows and MacOS X), so when multiple libraries export the same symbol, it could end up matching the symbol in the wrong library. Here, the user-defined malloc probably overrides libc's, resulting in a crash as it has different ABI/semantics, possibly corrupting memory too. -- 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=50257 --- Comment #13 from Alex S <iwtcex(a)gmail.com> --- (In reply to Damjan Jovanovic from comment #12)
ELF's symbol handling is generally a nightmare,
Still, our nightmare implementation is supposed to be compatible with GNU's. It's quite concerning if Linux behaves differently.
Here, the user-defined malloc probably overrides libc's, resulting in a crash as it has different ABI/semantics, possibly corrupting memory too.
In Gen's case the code simply crashes on the first (libc's internal) memory allocation, which is to be expected. The Wine issue is a bit more interesting: env LD_DEBUG=1 ./wine64 winecfg ... "calloc" in "libc.so.7" ==> 0x69626e00 in "ucrtbase.dll.so" reloc_jmpslot: *0x62245c18 = 0x69626e00 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! "_execve" in "libc.so.7" ==> 0x6963e1d0 in "ucrtbase.dll.so" ... "_exit" in "libc.so.7" ==> 0x69617190 in "ucrtbase.dll.so" ... -- 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=50257 --- Comment #14 from Gen Otsuji <otsugen0000(a)gmail.com> --- Hi, Thank you for testing on Linux. I'm sorry . the code on Linux also segfaults. But why does wine-6.0-rc4 on FreeBSD stuck? And why does wine-6.0-rc4 on Linux go well? I don't know. I tested env LD_DEBUG=1. My assumption is that, wine-6.0-rc4 is using malloc. and into the internal of malloc in heap.c, RtlAllocateHeap in ntdll/heap.c, TRACE => wine_dbg_log => vnsprintf. In vnsprintf,the malloc function is executed and it is recursion of malloc. so this malloc should be in libc. Thank you all. -- 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=50257 --- Comment #15 from Gen Otsuji <otsugen0000(a)gmail.com> --- It's assumption. sorry. -- 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=50257 --- Comment #16 from Gen Otsuji <otsugen0000(a)gmail.com> --- I think if something else is happening, too. -- 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=50257 --- Comment #17 from Gen Otsuji <otsugen0000(a)gmail.com> --- How about another assumption story? LD_DEBUG=1 ./wine winecfg shows malloc is in libc. so the malloc in wine-6.0-rc4 is not working. and nightmare. I'm confusing about recursion of malloc. My example code is recursion of malloc .(my assumption story) -- 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=50257 --- Comment #18 from Alex S <iwtcex(a)gmail.com> --- (In reply to Gen Otsuji from comment #17) With all due respect, we don't really need any kind of analysis. (If you want a workaround, use LD_BIND_NOW=1.) -- 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=50257 --- Comment #19 from Gen Otsuji <otsugen0000(a)gmail.com> --- (In reply to Alex S from comment #18)
(In reply to Gen Otsuji from comment #17)
With all due respect, we don't really need any kind of analysis.
(If you want a workaround, use LD_BIND_NOW=1.)
I'm sorry, I'll stop writing. -- 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=50257 --- Comment #20 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Alex S from comment #13)
env LD_DEBUG=1 ./wine64 winecfg ... "calloc" in "libc.so.7" ==> 0x69626e00 in "ucrtbase.dll.so" reloc_jmpslot: *0x62245c18 = 0x69626e00 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! "_execve" in "libc.so.7" ==> 0x6963e1d0 in "ucrtbase.dll.so" ... "_exit" in "libc.so.7" ==> 0x69617190 in "ucrtbase.dll.so"
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution. -- 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=50257 --- Comment #21 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
There seems to be something wrong with the Linux without-mingw build too. I've tested changing the "pow" function to "MSVCRT_pow" and it affects how often the function is called while running: wine nonexisting.exe When the function was called pow it was called 2048. It was called 0 times after changing the name to MSVCRT_pow. It was also not called in mingw builds no mater how function was named. -- 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=50257 --- Comment #22 from Alex S <iwtcex(a)gmail.com> --- (In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
Submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252307. -- 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=50257 --- Comment #23 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Piotr Caban from comment #21)
(In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
There seems to be something wrong with the Linux without-mingw build too. I've tested changing the "pow" function to "MSVCRT_pow" and it affects how often the function is called while running: wine nonexisting.exe
When the function was called pow it was called 2048. It was called 0 times after changing the name to MSVCRT_pow. It was also not called in mingw builds no mater how function was named.
Are you sure? pow() is called from the gdi32 font initialization, and it will be imported from ucrtbase also in non-mingw builds, so it should be called in all builds (unless the compiler inlines it). It shouldn't go through ELF linking at all. -- 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=50257 --- Comment #24 from Piotr Caban <piotr.caban(a)gmail.com> --- (In reply to Alexandre Julliard from comment #23)
Are you sure? No, I've done something wrong while testing, sorry.
-- 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=50257 robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robert.ayrapetyan(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=50257 --- Comment #25 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- Seems relevant, wine v6.2_1 (i386-wine-develop compiled with gcc10) on x64 gives: ... rtld_exit() calling fini function for /usr/bin/uname at 0x20322c calling fini function for /lib/libc.so.7 at 0x8003fdf40 calling fini function for /lib/libc.so.7 at 0x80040949c "_rtld_addr_phdr" in "libc.so.7" ==> 0x800213fd0 in "ld-elf.so.1" reloc_jmpslot: *0x80041cb48 = 0x800213fd0 lm_fini() lm_free(0x800232110) "_write" in "libc.so.7" ==> 0x8004078b0 in "libc.so.7" reloc_jmpslot: *0x80041bfc0 = 0x8004078b0 "_exit" in "libc.so.7" ==> 0x800398bb0 in "libc.so.7" reloc_jmpslot: *0x80041bcf0 = 0x800398bb0 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION (hangs here, waiting...) 0024:err:environ:run_wineboot boot event wait timed out 0024:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 003c:err:environ:run_wineboot boot event wait timed out 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:module:LdrInitializeThunk "ucrtbase.dll" failed to initialize, aborting 003c:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\services.exe" failed, status c0000142 003c:err:service:RPC_Init RpcServerListen failed with error 1721 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 002c:err:wineboot:start_services_process Couldn't start services.exe: error 1359 ^C0024:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0024:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\winecfg.exe" failed, status c000013a 0024:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting 0024:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\winecfg.exe" failed, status c000013a -- 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=50257 --- Comment #26 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- Btw when compiling with clang 10.0.1 on FreeBSD 12.2 x64 it fails with: ... tools/winegcc/winegcc -o dlls/activeds/activeds.dll.so --wine-objdir . -m64 -fPIC -fasynchronous-unwind-tables -shared \ dlls/activeds/activeds.spec -mno-cygwin dlls/activeds/activeds_main.o dlls/activeds/pathname.o \ dlls/activeds/activeds_r.res -ladvapi32 -lole32 -loleaut32 dlls/uuid/libuuid.a \ dlls/ucrtbase/libucrtbase.a -fstack-protector-strong ld: error: undefined symbol: __wine$func$ucrtbase$2264$ldexp
referenced by ucrtbase.UooaI2.o:(ldexp) in archive dlls/ucrtbase/libucrtbase.a
ld: error: undefined symbol: __wine$func$ucrtbase$2315$memset
referenced by ucrtbase.xoRUpg.o:(memset) in archive dlls/ucrtbase/libucrtbase.a cc: error: linker command failed with exit code 1 (use -v to see invocation) winegcc: /usr/bin/cc failed gmake[2]: *** [Makefile:1930: dlls/aclui/aclui.dll.so] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ...
so seems it just passes gcc10 unseen and fails only at a runtime. -- 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=50257 --- Comment #27 from Alex S <iwtcex(a)gmail.com> --- (In reply to robert.ayrapetyan from comment #26)
Btw when compiling with clang 10.0.1 on FreeBSD 12.2 x64 it fails with:
ld: error: undefined symbol: __wine$func$ucrtbase$2264$ldexp
That doesn't look like a valid symbol name. -- 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=50257 --- Comment #28 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- Yeah, but similar symbol is generated by gcc10 (only diff is a number): __wine$func$ucrtbase$2333$ldexp in dlls/ucrtbase/libucrtbase.a but somehow it proceeds with no errors... -- 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=50257 --- Comment #29 from Alex S <iwtcex(a)gmail.com> --- (In reply to robert.ayrapetyan(a)gmail.com from comment #28)
Yeah, but similar symbol is generated by gcc10 (only diff is a number):
__wine$func$ucrtbase$2333$ldexp
in dlls/ucrtbase/libucrtbase.a
but somehow it proceeds with no errors...
See https://source.winehq.org/git/wine.git/commit/aac69889bf1e276688895eca313dc8.... In any case, this a completely different issue. -- 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=50257 --- Comment #30 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- Sure, so what's the workaround for the original issues? How to perform: "You need to LD_PRELOAD your interposer" while building - a suggestion from Konstantin in a referred bug? -- 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=50257 --- Comment #31 from Alex S <iwtcex(a)gmail.com> --- (In reply to robert.ayrapetyan(a)gmail.com from comment #30)
Sure, so what's the workaround for the original issues?
Ctrl + F "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.
https://bugs.winehq.org/show_bug.cgi?id=50257 --- Comment #32 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- LD_BIND_NOW works for x64 on x64 build, but still gives: 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 003c:err:environ:run_wineboot boot event wait timed out 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:module:LdrInitializeThunk "ucrtbase.dll" failed to initialize, aborting 003c:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\system32\\services.exe" failed, status c0000142 003c:err:service:RPC_Init RpcServerListen failed with error 1721 002c:err:wineboot:start_services_process Couldn't start services.exe: error 1359 for i386 on x64. -- 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=50257 --- Comment #33 from Alex S <iwtcex(a)gmail.com> --- (In reply to robert.ayrapetyan(a)gmail.com from comment #32) It's LD_32_BIND_NOW for 32-bit apps on amd64. -- 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=50257 --- Comment #34 from robert.ayrapetyan(a)gmail.com <robert.ayrapetyan(a)gmail.com> --- Thanks, that worked. -- 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=50257 Graham Perrin <grahamperrin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grahamperrin(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=50257 --- Comment #35 from Graham Perrin <grahamperrin(a)gmail.com> --- (In reply to Piotr Caban from comment #5)
… also tried compiling 64-bit wine on FreeBSD. I didn't dig into it but I'm getting: wine: could not load ntdll.so: (null) both with and without "msvcrt: Remove MSVCRT_ prefix from heap.c functions" patch.
FYI <https://forums.FreeBSD.org/threads/77253/post-522107> -- 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=50257 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #36 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to Damjan Jovanovic from comment #2)
This only affects the ELF build, the PE build starts up fine.
Unfortunately mingw-w64 is still a work-in-progress on FreeBSD, so we use the ELF build exclusively.
I don't know what's problematic about getting mingw-w64 to work on FreeBSD, but for other options, recent Wine may be built with PE support using plain Clang. Clang supports cross compilation to PE targets with its default config and that's all we need, we don't need any other mingw addition. So, unless it's disabled for some reason on FreeBSD, you shouldn't need anything else. -- 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=50257 --- Comment #37 from Alex S <iwtcex(a)gmail.com> --- (In reply to Jacek Caban from comment #36)
I don't know what's problematic about getting mingw-w64 to work on FreeBSD,
mingw-w64 works fine, but it's a bit intimidating to package.
but for other options, recent Wine may be built with PE support using plain Clang. Clang supports cross compilation to PE targets with its default config and that's all we need, we don't need any other mingw addition.
That looks promising, however Clang can't find stdarg.h. I tried on the whim stdarg.h from FreeBSD, Glibc and Mingw-w64: Wine only sucessfully compiles with the header from Glibc. What's the deal with that? -- 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=50257 --- Comment #38 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to Alex S from comment #37)
That looks promising, however Clang can't find stdarg.h. I tried on the whim stdarg.h from FreeBSD, Glibc and Mingw-w64: Wine only sucessfully compiles with the header from Glibc. What's the deal with that?
stdarg.h is usually shipped with the compiler and Clang should provide one. Is it missing in your Clang installation (see eg. /usr/lib/clang/12.0.0/include/stdarg.h) for some reason? -- 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=50257 --- Comment #39 from Alex S <iwtcex(a)gmail.com> --- (In reply to Jacek Caban from comment #38)
stdarg.h is usually shipped with the compiler and Clang should provide one. Is it missing in your Clang installation (see eg. /usr/lib/clang/12.0.0/include/stdarg.h) for some reason?
Somehow it is missing; probably an oversight. Thank you for clarification though, at least I learned where to grab the correct header. Now we only have to hunt down a few extremely obnoxious Clang-related regressions*... Like the one where clang/lld builds a few remaining .dll.so's such as (BaseOfCode << 32) + AddressOfEntryPoint < ImageBase, which fixup_rva_ptrs seems to further mess up. * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231010 -- 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=50257 --- Comment #40 from Jacek Caban <jacek(a)codeweavers.com> --- Note that you may use a different compiler for .dll.so (I guess you were using GCC and you may continue to do so) and use clang only for PE parts. That's what configure should do by default when it can't mingw and clang is found, but if you want to be explicit, it's something like: configure CROSSCC=clang -- 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=50257 --- Comment #41 from Alex S <iwtcex(a)gmail.com> --- I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257533 regarding the PE build (for emulators/wine-devel port). We'll see how it goes. -- 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=50257 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #42 from Fabian Maurer <dark.shadow4(a)web.de> --- Is there any news regarding the original issue? The last posts seem to have gotten quite on a tangent. -- 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=50257 --- Comment #43 from Alex S <iwtcex(a)gmail.com> --- I'd suggest reading the thread again. And a few more times, if necessary. -- 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=50257 --- Comment #44 from Fabian Maurer <dark.shadow4(a)web.de> ---
I'd suggest reading the thread again. And a few more times, if necessary.
Rude. There hasn't been talk about the original issue for almost a year, therefore I feel the question is warranted. We're currently in bug-fix season, so IMHO this would be a good point to address the issue for the next stable. -- 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=50257 --- Comment #45 from Alex S <iwtcex(a)gmail.com> --- It's not at all a secret I positively _hate_ people with poor reading comprehension. The original issue (a presumed dynamic linker bug) is out of scope of Wine, it was reported to FreeBSD (PR 252307) and is quite unlikely to be fixed unless it inconveniences a significant number of people. -- 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=50257 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|pgofman(a)codeweavers.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=50257 --- Comment #46 from Austin English <austinenglish(a)gmail.com> --- (In reply to Alex S from comment #45)
It's not at all a secret I positively _hate_ people with poor reading comprehension.
That doesn't mean you need to reply in a rude way, particularly since the comment wasn't even directed at you, but on the bug in general, in such you're one of _several_ participants. -- 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=50257 Alex S <iwtcex(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|iwtcex(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=50257 --- Comment #47 from Fabian Maurer <dark.shadow4(a)web.de> --- Thank you Austin. Anyways, should be mark this as NOTOURBUG and simply wait for a FreeBSD fix? -- 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=50257 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED CC| |nerv(a)dawncrow.de --- Comment #48 from André H. <nerv(a)dawncrow.de> --- (In reply to Fabian Maurer from comment #47)
Thank you Austin. Anyways, should be mark this as NOTOURBUG and simply wait for a FreeBSD fix?
yes :) -- 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=50257 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression | -- 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