wine-devel-9.9,1 mitya@m18:~/Desktop % wine64 winbox64.exe 0024:fixme:ntdll:create_logical_proc_info stub 0024:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:fixme:ntdll:create_logical_proc_info stub 002c:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8cb17 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8cb17
wine-devel-9.10,1 % wine64 winbox64.exe 0024:fixme:ntdll:create_logical_proc_info stub 0024:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:fixme:ntdll:create_logical_proc_info stub 002c:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8cc37 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8cc37 winbox64 has obtained from https://mt.lv/winbox64
(In reply to Dmitry Lukhtionov from comment #1) See the comment here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279927#c10 Rebuilding wine-devel with that patch fixes the issue with Win64 binaries.
wine-devel-9.12,1 mitya@m18:~/Desktop % wine64 winbox64.exe 0024:fixme:ntdll:create_logical_proc_info stub 0024:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:fixme:ntdll:create_logical_proc_info stub 002c:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8b2b7 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8b2b7
Any news for me ? The error is reproduced on other computers.
Created attachment 252212 [details] Fix execution of Win64 binaries Here is a patch to fix the execution of Win64 binaries that typically result in a failure with a call to NtRaiseException. I did not write this; this is shamelessly stolen from the emulators/wine-proton port.
Can you attach this patch into port emulators/wine-devel ? I try to do some debug this. mitya@m18:~/Desktop % env WINEDEBUG=+seh,+relay wine64 winbox64.exe 0024:fixme:ntdll:create_logical_proc_info stub 0024:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:fixme:ntdll:create_logical_proc_info stub 002c:fixme:ntdll:init_cpu_info Failed to get logical processor information, status 0xc0000002. 002c:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00006FFFFFF8B2B7 002c:trace:seh:dispatch_exception info[0]=0000000000000001 002c:trace:seh:dispatch_exception info[1]=0000000000000000 002c:trace:seh:dispatch_exception rip=00006ffffff8b2b7 rsp=000000006853f7c8 rbp=0000000000000000 eflags=00010202 002c:trace:seh:dispatch_exception rax=0000000000000000 rbx=0000000000000000 rcx=00006ffffff8b2b7 rdx=0000000000000000 002c:trace:seh:dispatch_exception rsi=0000000000000000 rdi=0000000000000000 r8=0000000000000000 r9=0000000000000000 002c:trace:seh:dispatch_exception r10=0000000000000000 r11=0000000000000202 r12=0000000000000000 r13=0000000000000000 002c:trace:seh:dispatch_exception r14=0000000000000000 r15=0000000000000000 mxcsr=00001f80 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8b2b7 0024:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00006FFFFFF8B2B7 0024:trace:seh:dispatch_exception info[0]=0000000000000001 0024:trace:seh:dispatch_exception info[1]=0000000000000000 0024:trace:seh:dispatch_exception rip=00006ffffff8b2b7 rsp=000000000021f7c8 rbp=0000000000000000 eflags=00010202 0024:trace:seh:dispatch_exception rax=0000000000000000 rbx=0000000000000000 rcx=00006ffffff8b2b7 rdx=0000000000000000 0024:trace:seh:dispatch_exception rsi=0000000000000000 rdi=0000000000000000 r8=0000000000000000 r9=0000000000000000 0024:trace:seh:dispatch_exception r10=0000000000000000 r11=0000000000000202 r12=0000000000000000 r13=0000000000000000 0024:trace:seh:dispatch_exception r14=0000000000000000 r15=0000000000000000 mxcsr=00001f80 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8b2b7
Just more 0024: select() = PENDING { apc_handle=0000, signaled=0, call={}, contexts={} } 17704.773:0028:002c:trace:heap:RtlCreateHeap flags 0x2, addr 0000000000000000, total_size 0, commit_size 0, lock 0000000000000000, params 0000000000000000 17704.773:0028:002c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x0 00010000 2000 00000004 17704.773:0028:002c:trace:virtual:map_view got mem with anon mmap 0x35cf000-0x35df000 17704.773:0028:002c:trace:virtual:dump_view View: 0x35d0000 - 0x35dffff (valloc) 17704.773:0028:002c:trace:virtual:dump_view 0x35d0000 - 0x35dffff --rw- 17704.773:0028:002c:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00006FFFFFF8B2B7 17704.773:0028:002c:trace:seh:dispatch_exception info[0]=0000000000000001 17704.773:0028:002c:trace:seh:dispatch_exception info[1]=0000000000000000 17704.773:0028:002c:trace:seh:dispatch_exception rip=00006ffffff8b2b7 rsp=000000006853f7c8 rbp=0000000000000000 eflags=00010202 17704.773:0028:002c:trace:seh:dispatch_exception rax=0000000000000000 rbx=0000000000000000 rcx=00006ffffff8b2b7 rdx=0000000000000000 17704.773:0028:002c:trace:seh:dispatch_exception rsi=0000000000000000 rdi=0000000000000000 r8=0000000000000000 r9=0000000000000000 17704.773:0028:002c:trace:seh:dispatch_exception r10=0000000000000000 r11=0000000000000202 r12=0000000000000000 r13=0000000000000000 17704.773:0028:002c:trace:seh:dispatch_exception r14=0000000000000000 r15=0000000000000000 mxcsr=00001f80
(In reply to Dmitry Lukhtionov from comment #6) I am an alumni at this time, so I cannot commit anything.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ba5653b298e084faea153473a2eeefe2d0acd150 commit ba5653b298e084faea153473a2eeefe2d0acd150 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2024-07-29 21:47:34 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2024-07-29 21:47:34 +0000 emulators/wine-devel: Avoid "NtRaiseException Unhandled exception" Users have been reporting a number of cases of the following error: 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0 x6ffffff8b2b7 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0 Address this by means of a patch borrowed from emulators/wine-proton. PR: 279927, 280000 emulators/wine-devel/Makefile | 1 + .../files/patch-include_wine_asm.h (new) | 24 ++++++++++++++++++++++ 2 files changed, 25 insertions(+)
(In reply to Sean Farley from comment #8) > I am an alumni at this time, so I cannot commit anything. Too bad; I was hoping to hand over emulators/wine* finally. Thanks for confirming this patch which I had on my radar addresses the issue and getting others to test it as well. iwtcex@ is great at debugging and patching things; sadly they do not appear to care about upstream at all which is where this should have gone. So now I'll need to have a look how to go about this. :-(
(In reply to Gerald Pfeifer from comment #10) > they do not appear to care about upstream at all which is where this should have gone I don't like my real name being listed anywhere near my email address, especially not on the first page of Google results.
I saw this patch and was curious why it was needed, it didn't seem to be needed for my own upstream Wine build on FreeBSD. It turns out that clang/LLVM assembles 'jmp 1f' to a different length depending on optimization level. At -O0: 'e9 01 00 00 00', at -O2: 'eb 01'. GCC always outputs 'eb 01'. By default Wine uses '-g -O2' for CROSSCFLAGS, but maybe the port overrides this? Alex S, is it ok if I submit this upstream? Would you like me to credit you in the upstream commit message? If so, how? ("Based on a patch by Alex S"? Or a different name?)
Also, here are godbolt links to see the difference. PE: https://godbolt.org/z/35TxW8dK9 ELF: https://godbolt.org/z/1h3j4c4ja Adding -O1 to the clang side will make them equivalent (but of course Wine should not depend on this).
(In reply to Brendan Shanks from comment #12) > is it ok if I submit this upstream? Whatever you feel like doing. > Would you like me to credit you in the upstream commit message? Ditto. If that is too problematic, I might resubmit the patch following (rather obnoxious) upstream attribution rules, but I'm not in a hurry.
(In reply to Alex S from comment #11) > I don't like my real name being listed anywhere near my email address, > especially not on the first page of Google results. It's a pity, since your debugging and fixing really is great! On the other hand, thanks for sharing those patches via wine-proton - that's quite helpful.(In reply to Brendan Shanks from comment #12) (In reply to Brendan Shanks from comment #12) > It turns out that clang/LLVM assembles 'jmp 1f' to a different length > depending on optimization level. At -O0: 'e9 01 00 00 00', at -O2: > 'eb 01'. GCC always outputs 'eb 01'. That strikes me as suboptimal on LLVM's side - the shorter form should not require -O2, should it? Thank you for pushing this upstream, Brendan! Do you think this should/could go onto the 9.0 release branch as well?
(In reply to Gerald Pfeifer from comment #15) Sure, I created https://gitlab.winehq.org/wine/wine/-/merge_requests/6179 for this. I looked into the problem more: this behavior in Clang is triggered by '-mrelax-all' which -O0 currently passes, -O1 and higher do not. It was intended to speed compile times, but doesn't seem to have a noticeable effect any more. Sure enough, if you build with -O0 and pass '-mno-relax-all', jmp uses the shorter form. Also, Clang 19 will no longer pass '-mrelax-all' for -O0: https://maskray.me/blog/2024-04-27-clang-o0-output-branch-displacement-and-size-increase This would be a good candidate for the wine-stable branch but those releases don't seem to be happening this year, I'm not sure why. For the wine stable port, maybe using '-mno-relax-all' is an option? Or just applying this patch. Also, does this port set CFLAGS or CROSSCFLAGS when building? Wine uses '-g -O2' by default, which prevents this bug from showing up.
(In reply to Brendan Shanks from comment #16) > Also, does this port set CFLAGS or CROSSCFLAGS when building? Wine uses '-g -O2' by default, which prevents this bug from showing up. CROSSCFLAGS="-isystem ${FILESDIR}/clang" until https://github.com/FreeBSD/freebsd-ports/commit/c54ecc25f108da5e574e944938c19b078b0a11c7
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=33856e566b1098a567e48acba1add66ccc3ee4e4 commit 33856e566b1098a567e48acba1add66ccc3ee4e4 Author: Gerald Pfeifer <gerald@FreeBSD.org> AuthorDate: 2024-08-03 10:06:17 +0000 Commit: Gerald Pfeifer <gerald@FreeBSD.org> CommitDate: 2024-08-03 10:06:38 +0000 emulators/wine: Avoid "NtRaiseException Unhandled exception" This backports commit ba5653b298e084faea153473a2eeefe2d0acd150 Author: Gerald Pfeifer <gerald@FreeBSD.org> Date: Mon Jul 29 21:47:34 2024 +0000 from emulators/wine-devel. Users have been reporting a number of cases of the following error: 002c:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0x6ffffff8b2b7 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr 0 PR: 279927, 280000 emulators/wine/Makefile | 2 +- .../wine/files/patch-include_wine_asm.h (new) | 25 ++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-)
(In reply to Brendan Shanks from comment #16) > Sure, I created https://gitlab.winehq.org/wine/wine/-/merge_requests/6179 for this. Great, thank you. I saw this got merged, so we'll get a conflict with our local patch for the next snapshot at which point I'll drop that. And adopt the upstream patch instead of the current in case of the emulators/wine port. < I looked into the problem more: That's a nice analysis! Thank you for sharing. > This would be a good candidate for the wine-stable branch but those > releases don't seem to be happening this year, I'm not sure why. For > the wine stable port, maybe using '-mno-relax-all' is an option? Or > just applying this patch. Yes, carrying a local patch is not the end of the world, and I doubt too many are building from upstream sources. Most importantly the issue has been addressed on upstream trunk, so it's a matter of time until we can drop the local patch. :-)