https://bugs.winehq.org/show_bug.cgi?id=55710
Bug ID: 55710 Summary: wine-staging fails to run anything in 64-bit prefix Product: Wine-staging Version: 8.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dmitry@baikal.ru CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Even an attemp to create new 64-bit prefix fails:
$ WINEPREFIX=~/.wine64 WINEARCH=win64 ~/wine-staging64/wine winver wine: created the configuration directory '/home/dmitry/.wine64' 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.17 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 002c:fixme:sync:NtAcceptConnectPort ((nil),832,0x90000002,31,0x7ffffe0ff338,0x7d7d011256a0),stub! *** stack smashing detected ***: <unknown> terminated 002c:err:seh:call_stack_handlers invalid frame 00007FFFFE0FF320 (00007FFFFE102000-00007FFFFE200000) 002c:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
With 32-bit prefix everything seems to work. It looks like this problem started with wine-staging 8.16.
https://bugs.winehq.org/show_bug.cgi?id=55710
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
https://bugs.winehq.org/show_bug.cgi?id=55710
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #1 from Bernhard Übelacker bernhardu@mailbox.org --- Should this be visible with winehq staging binary packages too? On which linux distribution is this stack smashing showing?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Bernhard Übelacker from comment #1)
Should this be visible with winehq staging binary packages too?
Does that mean that you don't see this bug?
On which linux distribution is this stack smashing showing?
I tested with 2 different distributions, so I don't think that the problem is specific to some particular distribution.
I noticed that wine-staging 8.17.1 was released. Running 'wine winver' with an existing 64-bit prefix or an attempt to create a new one using wine-staging 8.17.1 no longer shows *** stack smashing detected ***: <unknown> terminated and simply hangs instead.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org ---
Does that mean that you don't see this bug?
No, I could not see it with the winehq staging binary packages 8.16~bookworm-1 or 8.17~bookworm-1, inside a minimal Debian Bookworm VM. It looks like there is no binary package for 8.17.1 available.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Bernhard Übelacker from comment #3)
Does that mean that you don't see this bug?
No, I could not see it with the winehq staging binary packages 8.16~bookworm-1 or 8.17~bookworm-1, inside a minimal Debian Bookworm VM. It looks like there is no binary package for 8.17.1 available.
Thanks. Just to clarify things: did you test with a 64-bit prefix?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #5 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to Dmitry Timoshkov from comment #2)
(In reply to Bernhard Übelacker from comment #1)
Should this be visible with winehq staging binary packages too?
Does that mean that you don't see this bug?
On which linux distribution is this stack smashing showing?
I tested with 2 different distributions, so I don't think that the problem is specific to some particular distribution.
I noticed that wine-staging 8.17.1 was released. Running 'wine winver' with an existing 64-bit prefix or an attempt to create a new one using wine-staging 8.17.1 no longer shows *** stack smashing detected ***: <unknown> terminated and simply hangs instead.
I also not able to reproduce the issue. wine-staging 8.17.1 was to fix a compile error for redhat. Can you please specify what redhat version? so we can duplicate that environment.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #6 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Dmitry Timoshkov from comment #4)
Thanks. Just to clarify things: did you test with a 64-bit prefix?
I installed wine-staging,wine-staging-amd64,wine-staging-i386 and tried following: WINEPREFIX=~/.wine64 WINEARCH=win64 /opt/wine-staging/bin/wine winver
But this did neither show the stack smashing, nor was hanging.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Bernhard Übelacker from comment #6)
(In reply to Dmitry Timoshkov from comment #4)
Thanks. Just to clarify things: did you test with a 64-bit prefix?
I installed wine-staging,wine-staging-amd64,wine-staging-i386 and tried following: WINEPREFIX=~/.wine64 WINEARCH=win64 /opt/wine-staging/bin/wine winver
But this did neither show the stack smashing, nor was hanging.
Do you know is that a mingw64 or clang build? I'm building Wine using clang, probably that could be related to the problem. I'll mention it once again: with winehq source this doesn't happen, neither does with 32-bit prefixes and wine-staging.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #8 from Bernhard Übelacker bernhardu@mailbox.org ---
Do you know is that a mingw64 or clang build? I'm building Wine using clang, probably that could be related to the problem. I'll mention it once again: with winehq source this doesn't happen, neither does with 32-bit prefixes and wine-staging.
I am sorry, but I don't know the details how the winehq staging binary packages get built.
Can you please share your clang version and your configure line? You don't use mingw-w64, so you also don't use llvm-mingw? So this is a non-PE build, instead a .dll.so build? And are you building a pure 64-bit build?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #9 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Bernhard Übelacker from comment #8)
Can you please share your clang version and your configure line? You don't use mingw-w64, so you also don't use llvm-mingw? So this is a non-PE build, instead a .dll.so build? And are you building a pure 64-bit build?
This is wow64 PE build, clang version is 11.0.1. There's nothing special passed to configure. This is a recent regression, wine-staging wow64 builds used to work just fine.
P.S. Since wine-staging doesn't use --backend=git-am by default and some of the patches in the staging tree have trailing spaces it's impossible to perform a proper git bisect to find the offending patchset.
https://bugs.winehq.org/show_bug.cgi?id=55710
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #10 from Jacek Caban jacek@codeweavers.com --- (In reply to Dmitry Timoshkov from comment #9)
There's nothing special passed to configure.
I guess that there is nothing special because you don't have mingw installed at all. For those who have mingw installed, a way to force using clang in MSVC mode is to use --with-mingw=clang.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Jacek Caban from comment #10)
(In reply to Dmitry Timoshkov from comment #9)
There's nothing special passed to configure.
I guess that there is nothing special because you don't have mingw installed at all. For those who have mingw installed, a way to force using clang in MSVC mode is to use --with-mingw=clang.
Or have CROSSCC=clang. I have it set in the start up script, sorry to not mention this, completely forgot about it.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #12 from Bernhard Übelacker bernhardu@mailbox.org --- I am sorry, but I don't get it configured with "Debian clang version 11.0.1-2", if there is just clang installed without gcc or mingw.
configure: error: The compiler doesn't support -mabi=ms. Use gcc instead of clang, or install mingw-w64. config.log: error: '__builtin_ms_va_start' used in System V ABI function
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #13 from Jacek Caban jacek@codeweavers.com --- You probably need to install lld as well.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #14 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Jacek Caban from comment #13)
You probably need to install lld as well.
Thanks a lot, with lld installed configuration succeeds.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #9)
Since wine-staging doesn't use --backend=git-am by default and some of the patches in the staging tree have trailing spaces it's impossible to perform a proper git bisect to find the offending patchset.
It doesn't use it by default, but is there anything preventing you from using --backend=git-am manually?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zeb Figura from comment #15)
(In reply to Dmitry Timoshkov from comment #9)
Since wine-staging doesn't use --backend=git-am by default and some of the patches in the staging tree have trailing spaces it's impossible to perform a proper git bisect to find the offending patchset.
It doesn't use it by default, but is there anything preventing you from using --backend=git-am manually?
Although I mentioned it already, probably I wasn't clear enough: specifying --backend=git-am leads to a failure to apply some of the staging patches. Probably patches with trailing spaces went in unnoticed because you don't use git-am which errors out in that case. Since the staged patches are supposed to be sent upstream at some point, they should be ready from the start, so I'd suggest to use --backend=git-am by default to spot such things earlier.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #17 from Zeb Figura z.figura12@gmail.com --- (In reply to Dmitry Timoshkov from comment #16)
(In reply to Zeb Figura from comment #15)
(In reply to Dmitry Timoshkov from comment #9)
Since wine-staging doesn't use --backend=git-am by default and some of the patches in the staging tree have trailing spaces it's impossible to perform a proper git bisect to find the offending patchset.
It doesn't use it by default, but is there anything preventing you from using --backend=git-am manually?
Although I mentioned it already, probably I wasn't clear enough: specifying --backend=git-am leads to a failure to apply some of the staging patches. Probably patches with trailing spaces went in unnoticed because you don't use git-am which errors out in that case.
I'm guessing you have "apply.whitespace = error" configured, which isn't the default. I'll push a change to explicitly lessen that to warn when applying wine-staging patches.
Not sure about Alistair, but I actually use `git apply' to rebase patches. That's not `git am', but it should be affected by the same configuration setting.
Since the staged patches are supposed to be sent upstream at some point, they should be ready from the start, so I'd suggest to use --backend=git-am by default to spot such things earlier.
Pretty much all wine-staging patches are riddled with enough problems that upstreaming is a whole process of fixing / rewriting anyway. The idea of performing incremental improvements on a patch while it's in the wine-staging repository is nice in theory, and I don't know, maybe it worked for Michael and Sebastian, but for us it's just extra busywork. Easier to take care of that when we actually have time to fix and upstream the patches themselves.
https://bugs.winehq.org/show_bug.cgi?id=55710
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #18 from Dmitry Timoshkov dmitry@baikal.ru --- According to the regression testing this bug is caused by
https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Sysca...
Author: Paul Gofman pgofman@codeweavers.com Date: Tue Jul 14 15:00:34 2020 +0300
ntdll: Support x86_64 syscall emulation.
Reverting this patch makes wine-staging able to run 64-bit applications.
Running with WINEDEBUG=+seh shows:
002c:trace:seh:install_bpf Installing seccomp filters. 002c:trace:seh:check_bpf_jit_enable enabled 0x31. 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.17 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 002c:trace:seh:sigsys_handler SIGSYS, rax 0x101, rip 0x32d9a1b56d. 002c:trace:seh:sigsys_handler SIGSYS, rax 0, rip 0x32d9a1b634. 002c:fixme:sync:NtAcceptConnectPort ((nil),832,0x90000002,31,0x7ffffe0ff338,0x7d7d01f6b000),stub! 002c:trace:seh:sigsys_handler SIGSYS, rax 0x3, rip 0x32d9a1b737. 002c:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7f55bef10eff ip=7f55bef10eff tid=002c 002c:trace:seh:handle_syscall_fault info[0]=0000000000000001 002c:trace:seh:handle_syscall_fault info[1]=0000000000000000 002c:trace:seh:handle_syscall_fault rax=00000000c000000d rbx=0000000000000001 rcx=0000000000000000 rdx=0000000000000000 002c:trace:seh:handle_syscall_fault rsi=000000007f07f900 rdi=0000000000000001 rbp=000000007f07f900 rsp=00007ffffe0ffa98 002c:trace:seh:handle_syscall_fault r8=0000000000000000 r9=00007ffffe0ff31f r10=00007f55bef4f640 r11=00000000fe0ff200 002c:trace:seh:handle_syscall_fault r12=0000000000000000 r13=0000000000000000 r14=0000000000000003 r15=0000000000000000 002c:trace:seh:handle_syscall_fault returning to user mode ip=00000032d9a1b737 ret=c0000005 *** stack smashing detected ***: <unknown> terminated
Paul, does that ring any bells? What kind of information would be helpful to investigate this further?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #19 from Paul Gofman pgofman@codeweavers.com --- The log suggests that there is something on 0x32d9a1b56d (and then 0x32d9a1b634, 0x32d9a1b737) having syscall instruction, and the intent of that code is probably to execute native Linux syscalls (judging by syscall numbers), that is, it is some native library. The usual reason for such things is stated right in the patch: "The known reasons are /proc/sys/vm/legacy_va_layout set to 1 or 'ulimit -s' being 'unlimited", but I doubt this is exactly the case here because there is a specific check during seccomp filters installation and it looks like glibc loaded at high addresses as patch expects.
Do you have some way to see what code (library) is loaded at those addresses? Not sure if it is easy to do remotely with additional patches, needs some extra logging to show at least Unix libs load addresses. Maybe +pid,+seh,+unwind,+virtual log can tell something, but only if it is *not* our Unix lib.
Not sure offhand what can it be (I guess it is clean prefix already), maybe something unusual in LD_PRELOAD? And just in case I would check ulimit -s and /proc/sys/vm/legacy_va_layout first.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #20 from Paul Gofman pgofman@codeweavers.com --- One guess that actually there is an upstream change made the patch broken. Now looking at commit histroy, I'd try with 25db1c5d49dc339e9b5a25514c198a524bd05484 upstream patch reverted, to see if that fixes the problem with the Staging patch. Is it maybe possible to bisect upstream with only this Staging patch on top?
Looking at that now it seems like that should've broken the patch for sure but in a different way: it would stop catching syscalls from Win libs now loaded at high addresses, not sure how the opposite can happen.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Paul Gofman from comment #20)
One guess that actually there is an upstream change made the patch broken. Now looking at commit histroy, I'd try with 25db1c5d49dc339e9b5a25514c198a524bd05484 upstream patch reverted, to see if that fixes the problem with the Staging patch.
No, reverting this commit didn't help. It's probably worth to mention that the problem started with at least wine-staging 8.16, which is earler than that commit date.
Is it maybe possible to bisect upstream with only this Staging patch on top?
It would be necessary to figure out first approximate time frame for the bisection.
Looking at that now it seems like that should've broken the patch for sure but in a different way: it would stop catching syscalls from Win libs now loaded at high addresses, not sure how the opposite can happen.
$ ulimit -s 8192
$ echo $LD_PRELOAD
$ cat /proc/sys/vm/legacy_va_layout 0
I'll see if I could figure out what is at the addresses RIP points to.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #22 from Paul Gofman pgofman@codeweavers.com --- I guess one quick way to approach what is at the address is to hack-insert infinite sleep into sigsys_handler with, e. g., Eax == 0 (letting test 0xffff syscall still to be processed), and then watch /proc/<pid>/maps.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #23 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Paul Gofman from comment #19)
The log suggests that there is something on 0x32d9a1b56d (and then 0x32d9a1b634, 0x32d9a1b737) having syscall instruction, and the intent of that code is probably to execute native Linux syscalls (judging by syscall numbers), that is, it is some native library. The usual reason for such things is stated right in the patch: "The known reasons are /proc/sys/vm/legacy_va_layout set to 1 or 'ulimit -s' being 'unlimited", but I doubt this is exactly the case here because there is a specific check during seccomp filters installation and it looks like glibc loaded at high addresses as patch expects.
Do you have some way to see what code (library) is loaded at those addresses? Not sure if it is easy to do remotely with additional patches, needs some extra logging to show at least Unix libs load addresses. Maybe +pid,+seh,+unwind,+virtual log can tell something, but only if it is *not* our Unix lib.
According to pmap there's nothing above 00000000ffcf0000.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #24 from Paul Gofman pgofman@codeweavers.com --- I am not sure what exactly pmap is doing (using /proc/pid/maps directly), but I don't think that's possible. Where are libc, vdso, everything?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #25 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Paul Gofman from comment #22)
I guess one quick way to approach what is at the address is to hack-insert infinite sleep into sigsys_handler with, e. g., Eax == 0 (letting test 0xffff syscall still to be processed), and then watch /proc/<pid>/maps.
/proc/<pid>/maps essentially matches what pmap lists.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #26 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 75257 --> https://bugs.winehq.org/attachment.cgi?id=75257 Contents /proc/pid/maps
Actually it looks like an operator's error happened. Let's try again.
Attached /proc/pid/maps matches the following +seh trace:
002c:trace:seh:install_bpf Installing seccomp filters. 002c:trace:seh:check_bpf_jit_enable enabled 0x31. 002c:fixme:winediag:LdrInitializeThunk wine-staging 8.17 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. 002c:trace:seh:sigsys_handler SIGSYS, rax 0x101, rip 0x32d9a1b56d. 002c:trace:seh:sigsys_handler SIGSYS, rax 0, rip 0x32d9a1b634. 002c:fixme:sync:NtAcceptConnectPort ((nil),832,0x90000002,207,0x7ffffe0ff2e8,0x7d7d010646e0),stub! 002c:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7feb67ee4360 ip=7feb67ee4360 tid=002c 002c:trace:seh:handle_syscall_fault info[0]=0000000000000008 002c:trace:seh:handle_syscall_fault info[1]=00007feb67ee4360
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #27 from Paul Gofman pgofman@codeweavers.com --- So it is /lib64/ld-2.27.so (dynamic loader) is getting loaded at low addresses for some reason. It is loaded by Wine preloader manually, that is, before any other Wine code works. I also don't see any Staging patches touching preloader.
I suspect some system change which triggered it. No immediate ideas how that can happen. Do you recall system wide changes / updates approximately when it could break?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #28 from Paul Gofman pgofman@codeweavers.com --- Also, are you sure that preloader in /lib64 is correct (and you are supposed to have glibc 2.27)? Normally those are in /usr/lib64 now. Which OS / version is that?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #29 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Paul Gofman from comment #27)
So it is /lib64/ld-2.27.so (dynamic loader) is getting loaded at low addresses for some reason. It is loaded by Wine preloader manually, that is, before any other Wine code works. I also don't see any Staging patches touching preloader.
I suspect some system change which triggered it. No immediate ideas how that can happen. Do you recall system wide changes / updates approximately when it could break?
No, I wouldn't connect system updates with this breakage, although that's certainly possible.
(In reply to Paul Gofman from comment #28)
Also, are you sure that preloader in /lib64 is correct (and you are supposed to have glibc 2.27)? Normally those are in /usr/lib64 now. Which OS / version is that?
$ /lib64/libc-2.27.so GNU C Library (GNU libc) stable release version 2.27. Copyright (C) 2018 Free Software Foundation, Inc. ...
$ cat /etc/redhat-release ALT Workstation 9.0 (Laertes)
Yes, this system has some obscure differences with Ubuntu/Redhat.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #30 from Paul Gofman pgofman@codeweavers.com --- Well, from the present info it is hard to guess what Wine or Staging change could cause it (if any). The patch in question catches syscalls based on address separation since long ago, nothing changed. It was disabled for some time (due to need for upstream rebase) and re-enabled not so long ago, maybe around the time of this breakage, so maybe system change which affected it happened earlier.
And yes, the way it separates syscalls is not a full proof solution by any means, it may be broken by certain non-standard (these days) setups, like, e. g., those two mentioned in the patch, there not much of sane options of fixing this specific problem (only if maybe additionally check for .elf loader address to disable patch effect if it is low, but that looks like rather arbitrary check very specific to this particular setup; it already checks for libc address which catches more common legacy VM configs in general).
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #31 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Paul Gofman from comment #30)
Well, from the present info it is hard to guess what Wine or Staging change could cause it (if any). The patch in question catches syscalls based on address separation since long ago, nothing changed. It was disabled for some time (due to need for upstream rebase) and re-enabled not so long ago, maybe around the time of this breakage, so maybe system change which affected it happened earlier.
And yes, the way it separates syscalls is not a full proof solution by any means, it may be broken by certain non-standard (these days) setups, like, e. g., those two mentioned in the patch, there not much of sane options of fixing this specific problem (only if maybe additionally check for .elf loader address to disable patch effect if it is low, but that looks like rather arbitrary check very specific to this particular setup; it already checks for libc address which catches more common legacy VM configs in general).
Paul, do you have any suggestions or an idea how to make the patch work on systems like the one I have here? Or the only solution is to disable the patch?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #32 from Paul Gofman pgofman@codeweavers.com ---
Paul, do you have any suggestions or an idea how to make the patch work on systems like the one I have here? Or the only solution is to disable the patch?
I am afraid, as I mentioned in the previous message, *this* patch cannot work with arbitrary native so addresses layout, there is no obvious way to make it address independent. It might be possible now, when PE split is complete, to implement that through Linux syscall thunk, although that won't work on 2018 system anyway and I am not working on that now.
So maybe it is possible to find what specifically causing this behaviuour on that system (some special ld.so build? not clear how that worked before though, something must have changed or actually that never worked on that system with this patch), or build with the patch disabled I am afraid.
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #33 from Zeb Figura z.figura12@gmail.com --- (In reply to Paul Gofman from comment #32)
Paul, do you have any suggestions or an idea how to make the patch work on systems like the one I have here? Or the only solution is to disable the patch?
I am afraid, as I mentioned in the previous message, *this* patch cannot work with arbitrary native so addresses layout, there is no obvious way to make it address independent. It might be possible now, when PE split is complete, to implement that through Linux syscall thunk, although that won't work on 2018 system anyway and I am not working on that now.
Wait, the PE split *is* complete now, right? We don't have any direct calls / callbacks anymore, or am I wrong?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #34 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Zeb Figura from comment #17)
I'm guessing you have "apply.whitespace = error" configured, which isn't the default. I'll push a change to explicitly lessen that to warn when applying wine-staging patches.
No, I don't have "apply.whitespace = error" in local or global .gitconfig.
Not sure about Alistair, but I actually use `git apply' to rebase patches. That's not `git am', but it should be affected by the same configuration setting.
Does it fail for you when applying https://github.com/wine-staging/wine-staging/blob/master/patches/vcomp_for_d... ?
If I specify --backend=git-am or use 'git am' to apply this patch I get
$ git am 0001-vcomp-Implement-_vcomp_for_dynamic_init_i8.patch Applying: vcomp: Implement _vcomp_for_dynamic_init_i8 .git/rebase-apply/patch:26: trailing whitespace.
.git/rebase-apply/patch:30: trailing whitespace.
warning: 2 lines add whitespace errors. * * You have some suspicious patch lines: * * In dlls/vcomp/main.c * trailing whitespace (line 1049) dlls/vcomp/main.c:1049: * trailing whitespace (line 1053) dlls/vcomp/main.c:1053:
and as a result I get broken git tree state and have to use 'git am --abort'.
On the other hand 'git apply' doesn't fail:
$ git apply 0001-vcomp-Implement-_vcomp_for_dynamic_init_i8.patch 0001-vcomp-Implement-_vcomp_for_dynamic_init_i8.patch:32: trailing whitespace.
0001-vcomp-Implement-_vcomp_for_dynamic_init_i8.patch:36: trailing whitespace.
warning: 2 lines add whitespace errors.
Could you please fix this patch so it applies cleanly?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #35 from Zeb Figura z.figura12@gmail.com --- It looks like that's coming from a pre-commit hook. I can't really find the source of that particular hook from an Internet search; it's clearly not stock (I don't have it), but I don't know who originally wrote it.
(In reply to Dmitry Timoshkov from comment #34)
Could you please fix this patch so it applies cleanly?
I'll fix it if I get time, but I'd really recommend you find a way to avoid depending on no whitespace errors in wine-staging patches. As it is, wine-staging can hardly be more than a repository for patches to live so that they don't get lost. Any actual upkeep we have to do is just an extra burden, that prevents us from getting time to ever upstream anything.
https://bugs.winehq.org/show_bug.cgi?id=55710
Aida Jonikienė aidas957@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aidas957@gmail.com
--- Comment #36 from Aida Jonikienė aidas957@gmail.com --- Does this issue still happen with wine-staging 8.21/9.0-rc4? Those versions of wine-staging work for me
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #37 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Aida Jonikienė from comment #36)
Does this issue still happen with wine-staging 8.21/9.0-rc4? Those versions of wine-staging work for me
Nothing has changed in the problematic staging patch, so, is there a reason to expect any change in the behaviour?
https://bugs.winehq.org/show_bug.cgi?id=55710
--- Comment #38 from Zeb Figura z.figura12@gmail.com --- (In reply to Aida Jonikienė from comment #36)
Does this issue still happen with wine-staging 8.21/9.0-rc4? Those versions of wine-staging work for me
This was always specific to the reporter's setup, so it's not surprising it's not reproducible elsewhere.
-
WineHQ Bugzilla