[Bug 46472] New: Linux kernel 4.19 breaks startup of BO2 due to change in PTRACE_POKEUSER hw breakpoint behavior
https://bugs.winehq.org/show_bug.cgi?id=46472
Bug ID: 46472 Summary: Linux kernel 4.19 breaks startup of BO2 due to change in PTRACE_POKEUSER hw breakpoint behavior Product: Wine Version: 4.0-rc6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: troyb@us.ibm.com Distribution: ---
Created attachment 63297 --> https://bugs.winehq.org/attachment.cgi?id=63297 linux 4.19 commit bd14406b78e6daa1ea3c1673bda1ffc9efdeead0
I bisected Linux 4.18 to 4.19 to find this commit which stops BO2 from launching under any version of wine from 3.12 to 4.0-rc6, attachment below. For convenience I hand-reverted the file kernel/events/hw_breakpoint.c as follows :
/** * modify_user_hw_breakpoint - modify a user-space hardware breakpoint * @bp: the breakpoint structure to modify * @attr: new breakpoint attributes */ int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr) { int err;
/* * modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it * will not be possible to raise IPIs that invoke __perf_event_disable. * So call the function directly after making sure we are targeting the * current task. */ if (irqs_disabled() && bp->ctx && bp->ctx->task == current) perf_event_disable_local(bp); else perf_event_disable(bp);
#if 0 /* new logic : >= kernel 4.19 */ err = modify_user_hw_breakpoint_check(bp, attr, false);
if (!bp->attr.disabled) perf_event_enable(bp);
return err; #else /* old logic : <kernel 4.19 */ if (!attr->disabled) { err = modify_user_hw_breakpoint_check(bp, attr, false); if (err) return err; perf_event_enable(bp); bp->attr.disabled=0; } return 0; #endif }
I examined some wine source code and found many instance of use of PTRACE_POKUSER. I don't know enough about this function to know if this kernel commit directly breaks the wine code, or some other fault in wine code is indirectly triggering the problem. Using "old logic" in the file hw_breakpoints above enables kernel 4.19 to start BO2 with 4.0-rc6 (and most likely others).
https://bugs.winehq.org/show_bug.cgi?id=46472
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- AFAIK the linux kernel shouldn't break userland programs. Reverting the kernel commit fixed the issue? If so, did you already ask on the linux mailinglist?
https://bugs.winehq.org/show_bug.cgi?id=46472
Anthony Jagers noonetinone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noonetinone@gmail.com
--- Comment #2 from Anthony Jagers noonetinone@gmail.com --- Which title is BO2. It would be helpful to add it to the affected applications list.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #3 from tjb troyb@us.ibm.com --- (In reply to Fabian Maurer from comment #1)
AFAIK the linux kernel shouldn't break userland programs. Reverting the kernel commit fixed the issue? If so, did you already ask on the linux mailinglist?
According to the commit, which I attached, this "corrected" behavior in PTRACE_POKUSER hardware breakpoint functions. I have no idea what this function is or what the "correct" behavior is supposed to be, so I would not even know what to ask on the kernel mailing list, all I can say is the change causes a program to bomb on wine which used to work. It needs to be addressed by an expert, i.e. a wine dev who used these commands and understands that this kernel patch is either broke, or the wine code is relying on unspecified behavior and needs to be updated.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #4 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #2)
Which title is BO2. It would be helpful to add it to the affected applications list.
I don't know how to do that. The program is Black Ops 2 , starting up the zombie mode, with or without DXVK.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #5 from tjb troyb@us.ibm.com --- (In reply to Fabian Maurer from comment #1)
AFAIK the linux kernel shouldn't break userland programs. Reverting the kernel commit fixed the issue? If so, did you already ask on the linux mailinglist?
To clarify further : There is some non-zero chance that the crash is actually the "correct" behavior due to other unrelated bugs, and in the previous version of the kernel (4.18 and below), the crash was not correctly trapped by the kernel logic/userspace interaction. This application only partially functions... it runs for about 35 minutes in game mode (solo zombies) and then freezes, sometimes with an "unhandled exception caught" message, but often just a freeze of one of the game threads while other threads continue running. After the kernel commit in 4.19, it doesn't even start, just immediately states "unhandled exception caught". There is also the chance that the kernel commit is just wrong... i.e. it changes semantics of the PTRACE_POKUSER in a way that is now incorrect.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #6 from Anthony Jagers noonetinone@gmail.com --- OK, I've added this bug to the addpdb page for this game. There is another bug report #41267. But, it never broaches the possibility that it was kernel related.
For me the built-in ship console pops up, with the message of an unhandled exception caught.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #7 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #6)
OK, I've added this bug to the addpdb page for this game. There is another bug report #41267. But, it never broaches the possibility that it was kernel related.
For me the built-in ship console pops up, with the message of an unhandled exception caught.
Thanks. The game still has a further bug in that it will only run for about 35 minutes (flawlessly though, both with and without DXVK) on the Nuketown map before it will just lock up, I suspect some issue with thread safe behavior but that bug is going to be very hard to track down, I don't even have an idea how to approach it at this point. I also don't know if the Linux kernel change is a problem with Linux (bad change) or wine (needs to set up PTRACE_POKUSER calls differently to comply with the new Linux change), I just don't know enough about these low level function interfaces.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #8 from Anthony Jagers noonetinone@gmail.com --- HOLY SH*T!
I reverted to kernel 4,18 and tib is right! In addition, F.E.A.R. 3 and Ghost Recon: Wildlands now work for me!
More test forthcoming!
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #9 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #8)
HOLY SH*T!
I reverted to kernel 4,18 and tib is right! In addition, F.E.A.R. 3 and Ghost Recon: Wildlands now work for me!
More test forthcoming!
Yay, progress :) Thanks for quick response!
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #10 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #8)
HOLY SH*T!
I reverted to kernel 4,18 and tib is right! In addition, F.E.A.R. 3 and Ghost Recon: Wildlands now work for me!
More test forthcoming!
If anyone reading this thread wants to take a look at the 35 minute lock up on the Black Ops 2 Nuketown map, heads up this is a "pro" map. Best strategy for casual player is to just ring-around-the rosie the zombies in round 1, after 35 min the game should freeze up. I am at wits end with this problem... can't seem to make anything impact it, native dlls, different computer, dxvk vs not etc. all the same. It can run on Linux 4.19 if you apply my hand reverted patch. If it doesn't lock up for you please post... might be I need to upgrade my ancient dist I am running slackware 14.2 3 years old now.
https://bugs.winehq.org/show_bug.cgi?id=46472
minion minion.procyk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |minion.procyk@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #11 from minion minion.procyk@gmail.com --- I am very excited to see this. I will try this out with the latest Black Ops to see if the game loads at all as I believe it was experiencing similar symptoms to Black Ops 2, and see if the game runs.
very nice find tjb.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #12 from minion minion.procyk@gmail.com --- well for shits and giggles i tried patching kernel 5.0.0-rc3 to see if that would work and it does not. Next up I'll try running kernel 4.18 and see if I can achieve similar results.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #13 from minion minion.procyk@gmail.com --- welp.
I was unable to get anything to launch. i tried compiling 4.18.2 and 5.0 rc3 with the patch applied and both black ops II and black ops 4 fail to launch a window. Tried with and without dxvk. Is there anything else yall are changing besides kernel?
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #14 from tjb troyb@us.ibm.com --- (In reply to minion from comment #13)
welp.
I was unable to get anything to launch. i tried compiling 4.18.2 and 5.0 rc3 with the patch applied and both black ops II and black ops 4 fail to launch a window. Tried with and without dxvk. Is there anything else yall are changing besides kernel?
I don't need to change kernel unless running 4.19, anything below 4.19 starts the game with both staging and non-staging wine >= 3.12 (tested). I installed steam with winetricks, it applies a dll override to disable overlay renderer. I use no other dll overrides unless dxvk is installed and then just dxvk overrides. I am running a nvidia card. I get identical behavior on slackware 14.2 and slackware current with latest glibc, which should be up to date with other distributions like arch, etc. I tried installing in both 32 bit prefix and 64 bit and get same results, game launches, runs for 35 minutes of play and freezes.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #15 from tjb troyb@us.ibm.com --- (In reply to tjb from comment #14)
(In reply to minion from comment #13)
welp.
I was unable to get anything to launch. i tried compiling 4.18.2 and 5.0 rc3 with the patch applied and both black ops II and black ops 4 fail to launch a window. Tried with and without dxvk. Is there anything else yall are changing besides kernel?
I don't need to change kernel unless running 4.19, anything below 4.19 starts the game with both staging and non-staging wine >= 3.12 (tested). I installed steam with winetricks, it applies a dll override to disable overlay renderer. I use no other dll overrides unless dxvk is installed and then just dxvk overrides. I am running a nvidia card. I get identical behavior on slackware 14.2 and slackware current with latest glibc, which should be up to date with other distributions like arch, etc. I tried installing in both 32 bit prefix and 64 bit and get same results, game launches, runs for 35 minutes of play and freezes.
I should clarify.. nuketown zombie map freezes after 30-35min. I played campaign mode I am sure for more than 1/2 hour with no lockups, haven't tried any other zombie maps.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #16 from minion minion.procyk@gmail.com --- interesting. I was using native steam app running via 3.16-6 proton using an AMD r9 380. Can you try running with the native steam app via proton and see if that works? I think it would also be worth posting on steam's proton issues tracker for this game to attract more testers and see if there are trends in nvidia gpus running successfully or not.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #17 from tjb troyb@us.ibm.com --- (In reply to minion from comment #16)
interesting. I was using native steam app running via 3.16-6 proton using an AMD r9 380. Can you try running with the native steam app via proton and see if that works? I think it would also be worth posting on steam's proton issues tracker for this game to attract more testers and see if there are trends in nvidia gpus running successfully or not.
Proton does not work at all. Both staging and non-staging wine will start the game.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #18 from minion minion.procyk@gmail.com --- gave it another shot running this under kernel 4.18.2 using wine-4.0 stable w/o dxvk and i still get no window launching. I'm also not smart enough to dork around with ptrace under wine. I couldn't get any log lines that would help hint at the issue. Taking a guess i'd say we're not providing the correct buffer and/or offsets for PTRACE_POKEUSER
There are lots of type conversions being done like unsigned longs being passed to methods requiring signed longs and vice versa, longs being passed as int parameters. I have very little experience with C and C++ so I'm not sure if these are potential issues or not.
I'd be interested to see someone shed a little light on this. I dorked around for a bit with no change. Will be happy to help where i can.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #19 from tjb troyb@us.ibm.com --- (In reply to minion from comment #18)
gave it another shot running this under kernel 4.18.2 using wine-4.0 stable w/o dxvk and i still get no window launching. I'm also not smart enough to dork around with ptrace under wine. I couldn't get any log lines that would help hint at the issue. Taking a guess i'd say we're not providing the correct buffer and/or offsets for PTRACE_POKEUSER
There are lots of type conversions being done like unsigned longs being passed to methods requiring signed longs and vice versa, longs being passed as int parameters. I have very little experience with C and C++ so I'm not sure if these are potential issues or not.
I'd be interested to see someone shed a little light on this. I dorked around for a bit with no change. Will be happy to help where i can.
It must have something to do with AMD vs Nvidia card then. Game plays fine for me except for the lockup after 35 minutes on Nuketown (same thing on very latest wine-4.0 stable) both with and without DXVK (though stuttery without DXVK). I am running a 10 series nvidia (gtx 1070) use vulkan beta driver 396.54.09. Vulkan shouldn't make a difference if not using DXVK. It seems the time related crash may be due to an eventual internal memory overrun, I think the game manages its own internal heap but must do mem ops through core wine so I think in multithreaded mode something relating to memory management is not thread safe and the heap is eventually overflowing. This game is definately multi threaded due to the way it crashes (player can still move around map on one thread after it locks up) so that is the only hint I have, something with threading over threaded abi is not thread safe, most likely going to be really hard to track down.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #20 from Anthony Jagers noonetinone@gmail.com --- I tried to file a bug report with the kernel mailing list. Either it got rejected or buried. Anyone else want to try?
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #21 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #20)
I tried to file a bug report with the kernel mailing list. Either it got rejected or buried. Anyone else want to try?
The kernel guys will need a specific example of why the patch is broken. The fact that wine used to work on some programs and doesn't work any more with new PTRACE_POKEUSER behavior is not going to matter to them unless it can be shown the change (claimed as a fix) is actually incorrect. Thus it most likely falls to a core wine dev to smoke this out, someone who actually implemented the low level PTRACE code and would know that the new interface behavior is incorrect, or that the new interface behavior is actually the correct approach and wine needs to be updated to accommodate it.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- (In reply to tjb from comment #21)
(In reply to Anthony Jagers from comment #20)
I tried to file a bug report with the kernel mailing list. Either it got rejected or buried. Anyone else want to try?
The kernel guys will need a specific example of why the patch is broken. The fact that wine used to work on some programs and doesn't work any more with new PTRACE_POKEUSER behavior is not going to matter to them unless it can be shown the change (claimed as a fix) is actually incorrect. Thus it most likely falls to a core wine dev to smoke this out, someone who actually implemented the low level PTRACE code and would know that the new interface behavior is incorrect, or that the new interface behavior is actually the correct approach and wine needs to be updated to accommodate it.
Did you actually talk to the kernel guys, or are you just guessing? They usually take backwards compatibility seriously.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #23 from Anthony Jagers noonetinone@gmail.com --- Good Morning, EST!
I just received a message from Greg K-H. He said that my bug report didn't get posted because of the bad url that I used. I knew that already and tried a different one which didn't work either. I guess I need for formally register to the mailing list.
He told me to contact the committer of the SHA1 tjb identified in the first post.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #24 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #23)
Good Morning, EST!
I just received a message from Greg K-H. He said that my bug report didn't get posted because of the bad url that I used. I knew that already and tried a different one which didn't work either. I guess I need for formally register to the mailing list.
He told me to contact the committer of the SHA1 tjb identified in the first post.
Great. Combo of Greg, patch authors, and author of wine's server/ptrace.c should be able to sort out the issue to see if Linux 4.19+ patch needs to be modified or wine updated to handle the new behavor.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #25 from Anthony Jagers noonetinone@gmail.com ---
...to see if Linux 4.19+ patch needs to be modified or wine updated to handle >>>the new behavor.
That would be up to Julliard to determine that. We should wait for his response.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #26 from Alexandre Julliard julliard@winehq.org --- If the kernel can't be fixed, of course we will have to add a workaround, but that's not going to help users running existing Wine versions. Preserving backwards compatibility would be preferable.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #27 from tjb troyb@us.ibm.com --- (In reply to Alexandre Julliard from comment #22)
(In reply to tjb from comment #21)
(In reply to Anthony Jagers from comment #20)
I tried to file a bug report with the kernel mailing list. Either it got rejected or buried. Anyone else want to try?
The kernel guys will need a specific example of why the patch is broken. The fact that wine used to work on some programs and doesn't work any more with new PTRACE_POKEUSER behavior is not going to matter to them unless it can be shown the change (claimed as a fix) is actually incorrect. Thus it most likely falls to a core wine dev to smoke this out, someone who actually implemented the low level PTRACE code and would know that the new interface behavior is incorrect, or that the new interface behavior is actually the correct approach and wine needs to be updated to accommodate it.
Did you actually talk to the kernel guys, or are you just guessing? They usually take backwards compatibility seriously.
I stated this because there is some (probably small) chance that the affected programs (BO2 and others Anthony found) should be crashing due to issues unrelated to this change, and the kernel change now "correctly" traps the error. If this can be shown definatively false (i.e. the change breaks something in userspace which used to work), then there is a better argument for preserving the backward compatible behavior unless an argument can be made that the change is actually needed for some other very solid reason.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #28 from Anthony Jagers noonetinone@gmail.com --- By request, I emailed the maintainers of the source file: hw_breakpoint.c and got a response back from the committer. They wrote that from us they need concrete examples of the error that tjb suggested in Comment 21.
That means we need to post better terminal output for the kernel developer to read. I'll try and do that. Any suggestions for applicable debug channels?
I await a response from the linux kernel mailing list when a bug report is filed and will share a link when I have one.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #29 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #28)
By request, I emailed the maintainers of the source file: hw_breakpoint.c and got a response back from the committer. They wrote that from us they need concrete examples of the error that tjb suggested in Comment 21.
That means we need to post better terminal output for the kernel developer to read. I'll try and do that. Any suggestions for applicable debug channels?
I await a response from the linux kernel mailing list when a bug report is filed and will share a link when I have one.
I can't get the program to run under valgrind, winedbg, or winedbg with gdb. It may be detecting the debugger hooks and failing intentionally in unrelated code as a crack defense (COD WaW will also messagebox with a debugger detected message and halt). One solution I thought of may be a programmed breakpoint in MessageBoxA and manual backtrace (i.e. modify messagebox wine code with a break at the entry to messageboxa then call a manual backtrace). That would at least give a backtrace of the crash which happens when the kernel has the new ptrace code, but still may not point to the actual problem (most likely ptrace.c needs to be updated to handle the new interface). A more experienced wine debugger may know a way to circumvent the crashes when debugger is activated, i.e. attach to the program after it messageboxes with the unhandled exception caught and get the backtrace, but still may not point directly to the ptrace issue. It seems to me that a better way to approach this may be to understand the implicationss of the new PTRACE_POKEUSER behavior on the wine ptrace code and conclude from that why it doesn't work like it used to, not try to back-trace the actual crash in any given program.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #30 from Anthony Jagers noonetinone@gmail.com --- Update, I have received a flurry of emails since I CC'ed the five maintainers of the source file.
I'll just quote what two unnamed individuals have wrote.
there's a post with simple test code showing what the fix aimed for: https://lore.kernel.org/lkml/tip-9b3579fc6c6ac45502de1fa9a1fdf873805c2157@gi...
it might help narow down the potential issue in set_thread_context
Someone with access to the app will need to investigate what it's doing, specifically how it's trying to set the debug registers and why the values that it's setting are causing different behavior with that kernel change. Getting an strace of the wineserver process would probably help, or else adding printfs to all the PTRACE_PEEKUSER/POKEUSER calls in server/ptrace.c.
_______________________________________________________________________________
Well that's something.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #31 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #30)
Update, I have received a flurry of emails since I CC'ed the five maintainers of the source file.
I'll just quote what two unnamed individuals have wrote.
there's a post with simple test code showing what the fix aimed for: https://lore.kernel.org/lkml/tip-9b3579fc6c6ac45502de1fa9a1fdf873805c2157@gi...
it might help narow down the potential issue in set_thread_context
Someone with access to the app will need to investigate what it's doing, specifically how it's trying to set the debug registers and why the values that it's setting are causing different behavior with that kernel change. Getting an strace of the wineserver process would probably help, or else adding printfs to all the PTRACE_PEEKUSER/POKEUSER calls in server/ptrace.c.
__
Well that's something.
I tried intercepting the peek and poke calls in ptrace.c but it seems the program never gets there ... either pilot error on my part (someone should independently check), or some other library got affected by the kernel change (maybe even the Nvidia binary blob... but it works fine with other wine programs besides BO2 on 4.19 with the new breakpoint behavior). Cue twilight zone jingle.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #32 from tjb troyb@us.ibm.com --- Created attachment 63595 --> https://bugs.winehq.org/attachment.cgi?id=63595 klog for case which launches game, old kernel breakpoint logic
kernel 4.19 hw_breakpoints.c patched to old behavior with trace code compiled in.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #33 from tjb troyb@us.ibm.com --- Created attachment 63596 --> https://bugs.winehq.org/attachment.cgi?id=63596 klog for case which crashes, new kernel breakpoint logic
Kernel 4.19 hw_breakpoints.c using new kernel logic which sets breakpoint if attr is disabled.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #34 from tjb troyb@us.ibm.com --- (In reply to tjb from comment #31)
(In reply to Anthony Jagers from comment #30)
Update, I have received a flurry of emails since I CC'ed the five maintainers of the source file.
I'll just quote what two unnamed individuals have wrote.
there's a post with simple test code showing what the fix aimed for: https://lore.kernel.org/lkml/tip-9b3579fc6c6ac45502de1fa9a1fdf873805c2157@gi...
it might help narow down the potential issue in set_thread_context
Someone with access to the app will need to investigate what it's doing, specifically how it's trying to set the debug registers and why the values that it's setting are causing different behavior with that kernel change. Getting an strace of the wineserver process would probably help, or else adding printfs to all the PTRACE_PEEKUSER/POKEUSER calls in server/ptrace.c.
__
Well that's something.
I tried intercepting the peek and poke calls in ptrace.c but it seems the program never gets there ... either pilot error on my part (someone should independently check), or some other library got affected by the kernel change (maybe even the Nvidia binary blob... but it works fine with other wine programs besides BO2 on 4.19 with the new breakpoint behavior). Cue twilight zone jingle.
Instead of trying to pinpoint all wineserver ptrace calls I modified the kernel hw_breakpoints.c function to add some diagnostics to the output to capture what is going on. The debug code is given below. klogs for the cases where it starts the game (using old breakpointlogic) and the case where it crashes with an unhandled exception caught (new breakpoint logic) are attached to the bug report.
/** * modify_user_hw_breakpoint - modify a user-space hardware breakpoint * @bp: the breakpoint structure to modify * @attr: new breakpoint attributes */ int modify_user_hw_breakpoint(struct perf_event *bp, struct perf_event_attr *attr) { int err;
/* * modify_user_hw_breakpoint can be invoked with IRQs disabled and hence it * will not be possible to raise IPIs that invoke __perf_event_disable. * So call the function directly after making sure we are targeting the * current task. */ if (irqs_disabled() && bp->ctx && bp->ctx->task == current) perf_event_disable_local(bp); else perf_event_disable(bp);
#if 1 /* new logic : >= kernel 4.19 */ printk("New logic modify breakpoint. Callstack :\n"); dump_stack();
err = modify_user_hw_breakpoint_check(bp, attr, false);
printk("Breakpoint modified err %d disabled %d\n",err,bp->attr.disabled);
if (!bp->attr.disabled) perf_event_enable(bp);
return err; #else
printk("Old logic modify breakpoint. Callstack :\n"); dump_stack();
/* old logic : <kernel 4.19 */ if (!attr->disabled) { err = modify_user_hw_breakpoint_check(bp, attr, false); printk("Breakpoint modified err %d disabled %d\n",err,bp->attr.disabled); if (err) return err; perf_event_enable(bp); bp->attr.disabled=0; } else printk("Breakpoint disabled : not modified\n");
return 0; #endif }
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #35 from tjb troyb@us.ibm.com --- I corrected my pilot error in intercepting peeks and pokes. The code I used is added to server/ptrace.c as follows, where ptrace call is replaced with ptraced for ever POKEUSER and PEEKUSER. I attached the results for the crash case (new hw breakpoint code in 4.19) and for the successful launch case (same 4.19 kernel with hw breakpoint reverted to previous behavior).
#if 1 long ptraced(enum __ptrace_request request, pid_t pid, void *addr, void *data)
{ if (request == PTRACE_POKEUSER) fprintf(stderr,"PTRACE_POKEUSER pid %x addr %p data %p\n",pid,addr,data); else if (request == PTRACE_PEEKUSER) fprintf(stderr,"PTRACE_PEEKUSER pid %x addr %p data %p\n",pid,addr,data);
return(ptrace(request,pid,addr,data)); } #else #define ptraced(request,pid,addr,data) ptrace(request,pid,addr,data) #endif
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #36 from tjb troyb@us.ibm.com --- Created attachment 63600 --> https://bugs.winehq.org/attachment.cgi?id=63600 ptrace debug log for crash launch (new kernel hw_breakpoint)
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #37 from tjb troyb@us.ibm.com --- Created attachment 63601 --> https://bugs.winehq.org/attachment.cgi?id=63601 ptrace debug log for successful launch (old hw_breakpoint code)
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #38 from Anthony Jagers noonetinone@gmail.com --- There are five fprintf calls in server/ptrace.c. Only if debug_level is set will they emit. The wine developers have it set to zero permanently. Also, there is no debug channel for the server.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #39 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #38)
There are five fprintf calls in server/ptrace.c. Only if debug_level is set will they emit. The wine developers have it set to zero permanently. Also, there is no debug channel for the server.
I modified ptrace.c with the code posted in an earlier message to intercept the peek and poke ptrace calls. fprintf(stderr,...) always outputs.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #40 from Anthony Jagers noonetinone@gmail.com --- I'm looking for a good 4.18 kernel tree. Greg K-H EOL'd his branch. I tried Ubuntu's but they have modified the build system and it needs system utilities which I don't have.
https://bugs.winehq.org/show_bug.cgi?id=46472
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #41 from tjb troyb@us.ibm.com --- (In reply to Anthony Jagers from comment #40)
I'm looking for a good 4.18 kernel tree. Greg K-H EOL'd his branch. I tried Ubuntu's but they have modified the build system and it needs system utilities which I don't have.
I bisected using the last 4.18 version on kernel.org, i.e. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.18.19.tar.xz
It is also possible to just modify kernel/events/hw_breakpoint.c with the code I posted in this thread and configure it for new or old breakpoint behavior with the conditional compile, it will work the same way as unpatched 4.18 regarding the ptrace behavior. I have been running reverted linux 4.19 for many weeks with no issues found.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #42 from tjb troyb@us.ibm.com --- (In reply to tjb from comment #41)
(In reply to Anthony Jagers from comment #40)
I'm looking for a good 4.18 kernel tree. Greg K-H EOL'd his branch. I tried Ubuntu's but they have modified the build system and it needs system utilities which I don't have.
I bisected using the last 4.18 version on kernel.org, i.e. https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.18.19.tar.xz
It is also possible to just modify kernel/events/hw_breakpoint.c with the code I posted in this thread and configure it for new or old breakpoint behavior with the conditional compile, it will work the same way as unpatched 4.18 regarding the ptrace behavior. I have been running reverted linux 4.19 for many weeks with no issues found.
Actually take that back.. I bisected from a git clone of Linus' kernel tree on github which didn't even have the 4.18.19 version... Linus' tree doesn't seem to incorporate the patch updates after a version release. The bisect was done between release 4.18 stable and release 4.19 stable. However I don't think there was any code change from that version to 4.18.19 regarding the hw_breakpoints.c code.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #43 from tjb troyb@us.ibm.com --- I dug a little into the ptrace/hw breakpoint stuff tonight. One thing which looked suspicious to me from the traces I posted was that the program crashed nearly immediately after a poke of 0x11110055 to dr7. The first klog in the old kernel code showed breakpoint disabled and skipped during this call. However the new kernel code will always set the breakpoint. The problem might be that poking 0x11110055 to dr7 before the breakpoing address registers are even set is enabling breakpoints with either uninitialized or unwanted tracepoints. To test this out I updated server/ptrace.c to zero out the breakpoint addressess (0 should never be hit) before poking the 0x11110055.
. . .
ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(0), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(1), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(2), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(3), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(6), 0x00000000 ); ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(7), 0x11110055 );
switch (context->cpu)
. . .
and voila now BO2 starts with the new kernel breakpoint behavior introduced in Linux 4.19. This should also work fine with previous breakpoint behavior in Linux <4.19. I don't know if this is the "right" fix but it does appear that the previous kernel breakpoint behavior may have been covering up a wine bug where it was enabling breakpoints in dr7 without first configuring the breakpoint addresses, i.e. the new kernel code may have exposed a latent bug in wine.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #44 from tjb troyb@us.ibm.com --- Verified the patch I added to server/ptrace.c will start BO2 with both old breakpoint behavior (<Kernel 4.19) and new (Kernel >= 4.19) behavior.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #45 from tjb troyb@us.ibm.com --- Created attachment 63662 --> https://bugs.winehq.org/attachment.cgi?id=63662 server/ptrace.c test patch for new kernel breakpoints
This is a test patch to wineserver ptrace.c to enable BO2 zombies to launch on Linux kernel >= 4.19. I can't guarantee this won't break something else so use it at your own risk. Better to wait for wine team to create official fix if you are in doubt.
https://bugs.winehq.org/show_bug.cgi?id=46472
Lectrode electrodexsnet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |electrodexsnet@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46472
Stefan Riesenberger stefan.riesenberger@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan.riesenberger@gmail.c | |om
--- Comment #46 from Stefan Riesenberger stefan.riesenberger@gmail.com --- tjb you are the best! This patch fixes the "Unhandled exception" error in bo2 for me on Linux 5.0.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #47 from tjb troyb@us.ibm.com --- (In reply to Stefan Riesenberger from comment #46)
tjb you are the best! This patch fixes the "Unhandled exception" error in bo2 for me on Linux 5.0.
Thanks for the feedback! I am not sure it is the best solution but it seemed to work on both old (<=4.18) and new Linux versions on my setup (I am running 4.19 long term). As far as I know hw_breakpoint.c behavior has not been modified since 4.19, good to hear it continues to work on latest Linux release also.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #48 from Anthony Jagers noonetinone@gmail.com --- I mentioned Ghost Recon: Wildlands. But with updates to wine/uplay & kernel 5.1 the game appears unaffected. The other titles remain broken.
https://bugs.winehq.org/show_bug.cgi?id=46472
christiangigante12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |christiangigante12@gmail.co | |m
--- Comment #49 from christiangigante12@gmail.com --- Hi I've builded wine 4.8 with the ptrace patch and Black Ops 2 started fine the menu was also fine but when i get in game it starts to freeze every 2 seconds. I've tried with different dxvk versions and with wined3d but it didn't solve the problem. Maybe something is changed in the kernel 5.1 that i'm running?
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #50 from Stefan Riesenberger stefan.riesenberger@gmail.com --- The game stutter has nothing to do with this bug. It only occurs in Zombie-Mode, for me at least, and is probably a networking issue in wine. It happens when the wine user is the lobby host (this also applies to solo mode).
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #51 from tjb troyb@us.ibm.com --- (In reply to Stefan Riesenberger from comment #50)
I have only tested zombie solo mode extensively and there is no periodic stutter at all in my setup on kernel 4.19. Wine 4.8 staging seems to have filesystem access problems possibly related to new symlink patches, so I also revered to Wine 4.7 staging. Very intermittently the game will report that the user rank is corrupted and it restores it from last saved rank, otherwise it runs platinum level.. perfect rendering and up to 200fps with a gtx1070/1080p with latest dxvks (1.2+).
https://bugs.winehq.org/show_bug.cgi?id=46472
maniikarabera@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maniikarabera@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=46472
andy andy86@fastwebnet.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andy86@fastwebnet.it, | |z.figura12@gmail.com
--- Comment #52 from andy andy86@fastwebnet.it --- Still present in last wine version (5.5), block Risen 2 for me (crash when load/start game) but patch posted by tjb fixed issue for me.
I think this bug should be confirmed and have some priority.
https://bugs.winehq.org/show_bug.cgi?id=46472
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46472
mo78@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mo78@abv.bg
--- Comment #53 from mo78@abv.bg --- Can confirm, the problem is still here with Wine 5.6.
Status "Unconfirmed"???
https://bugs.winehq.org/show_bug.cgi?id=46472
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #54 from mirh mirh@protonmail.ch --- Can you check wine 5.7 or higher? A set_thread_context fix landed.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #55 from tjb troyb@us.ibm.com --- (In reply to mirh from comment #54)
Can you check wine 5.7 or higher? A set_thread_context fix landed.
Still crashes with unhandled exception on wine 5.8 without my patch to server/ptrace.c, works fine with my patch applied.
https://bugs.winehq.org/show_bug.cgi?id=46472
brunnenschacht.eins@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brunnenschacht.eins@web.de
--- Comment #56 from brunnenschacht.eins@web.de --- (In reply to andy from comment #52)
Still present in last wine version (5.5), block Risen 2 for me (crash when load/start game) but patch posted by tjb fixed issue for me.
I think this bug should be confirmed and have some priority.
hi, which version of the game (Risen 2) are you using, Steam, GOG ?
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #57 from andy andy86@fastwebnet.it --- (In reply to brunnenschacht.eins from comment #56)
(In reply to andy from comment #52)
hi, which version of the game (Risen 2) are you using, Steam, GOG ?
Hi, I'm using steam version trough retail dvd.
https://bugs.winehq.org/show_bug.cgi?id=46472
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.goosev@gmail.com
--- Comment #58 from Andrey Gusev andrey.goosev@gmail.com --- *** Bug 46158 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #59 from andy andy86@fastwebnet.it --- Risen 2 still crash in wine 6.12.
tjb Patch "does not apply" anymore.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #60 from tjb troyb@us.ibm.com --- (In reply to andy from comment #59)
Risen 2 still crash in wine 6.12.
tjb Patch "does not apply" anymore.
Still applies on git master as of June 28. (no 6.12 tags in the wine git). Im not following the 6 series wine releases. If its broke after the 6.12 release drop another comment on the bugzilla and I'll take a look. Its a very simple patch.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #61 from andy andy86@fastwebnet.it --- Sorry, I made a typo. I meant wine-6.11.
Anyway patch do not applies for me on git master as of June 28.
Taking a look in a code seems I need to change:
- switch (context->cpu) + switch (context->machine)
to make it apply.
After this Risen 2 can work in Wine.
https://bugs.winehq.org/show_bug.cgi?id=46472
GloriousEggroll@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |GloriousEggroll@gmail.com
--- Comment #62 from GloriousEggroll@gmail.com --- Seems this is broken again.
With the patch applied to 6.20, the game does launch, but a few seconds into the music playing on the menu the same unhandled exception pops up.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #63 from tjb troyb@us.ibm.com --- (In reply to GloriousEggroll from comment #62)
Seems this is broken again.
With the patch applied to 6.20, the game does launch, but a few seconds into the music playing on the menu the same unhandled exception pops up.
Im not following wine development but gave 6.20 a try (with dxvk 1.9.2) and it still runs for me except for crackling audio. Most likely you are running out of 32 bit address space as wine 6 development series is bloating too much into 32 bit address space for some games to run. (the unhandled exception is a generic trap which in your case is now most likely trigger on an unhandled memory overlow) I run 6.1 with manually added spatial audio patches where 32 bit bloating is not bad enough to stop the 32b games I have from running (Waw is the most sensitive one I have to the bloating).
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #64 from Stefan Riesenberger stefan.riesenberger@gmail.com --- I can confirm that the patches 218416 and 218415 fix this issue for me. Black Ops 2 Zombies is starting fine now.
https://bugs.winehq.org/show_bug.cgi?id=46472
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #65 from winetest@luukku.com --- (In reply to Stefan Riesenberger from comment #64)
I can confirm that the patches 218416 and 218415 fix this issue for me. Black Ops 2 Zombies is starting fine now.
I believe both patches were merged into wine and will be in next release (6.21).
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #66 from Lectrode electrodexsnet@gmail.com --- @winetest commit?
i saw this commit: https://source.winehq.org/git/wine.git/commitdiff/75bccf99d1f90555c998f2c9b9...
it seems to be doing the opposite (removing register workarounds).
i compiled the latest vanilla wine-git and black ops 2 has the same unhandled exception issue. recompiling with patch 63662 allows the game to get past that error (tested on kernel 5.13)
(running into a directx issue now, but it's unrelated to this one)
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #67 from Lectrode electrodexsnet@gmail.com --- quick follow up: fixed directx issue by disabling nvapi support (new default in lutris). game is running like normal (hangs on close, and sometimes needs to be re-launched to connect to online services, but these are unrelated issues)
findings are the same: unhandled exception with wine-git as is, and playable once those 5 ptrace lines are added from attachment 63662.
(latest commit on wine-git as of testing was 5f93c683ab0163cb34482fe18549cf249b8b074b )
https://bugs.winehq.org/show_bug.cgi?id=46472
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #68 from Paul Gofman pgofman@codeweavers.com --- I think you need the whole series (2 patches), not just one. Since that is upstream now I'd suggest retesting with the current git.
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #69 from tjb troyb@us.ibm.com --- (In reply to Lectrode from comment #67)
quick follow up: fixed directx issue by disabling nvapi support (new default in lutris). game is running like normal (hangs on close, and sometimes needs to be re-launched to connect to online services, but these are unrelated issues)
findings are the same: unhandled exception with wine-git as is, and playable once those 5 ptrace lines are added from attachment 63662 [details].
(latest commit on wine-git as of testing was 5f93c683ab0163cb34482fe18549cf249b8b074b )
My ptrace patches are only needed if the ptrace poke to 0x11115555 is still in the code (this poke turned on interrupts for uninitialized trap addresses which caused the unhandled exception crash). If the 0x11115555 poke is removed (most likely removing workarounds and support for earlier linux versions) the trap addresses should not need to be iniitialized with 0s (an address which won't be hit)
https://bugs.winehq.org/show_bug.cgi?id=46472
--- Comment #70 from Lectrode electrodexsnet@gmail.com --- apparently i got my wires crossed or something. i wiped everything and redid the tests from scratch. i can confirm that black ops 2 launches now with vanilla wine-git. thank you
https://bugs.winehq.org/show_bug.cgi?id=46472
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |75bccf99d1f90555c998f2c9b90 | |7ed9292ce47f3 Summary|Linux kernel 4.19 breaks |Linux kernel 4.19 breaks |startup of BO2 due to |startup of Call of Duty: |change in PTRACE_POKEUSER |Black Ops II due to change |hw breakpoint behavior |in PTRACE_POKEUSER hw | |breakpoint behavior Component|-unknown |ntdll Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #71 from Matteo Bruni matteo.mystral@gmail.com --- Reported fixed, thanks for testing.
https://bugs.winehq.org/show_bug.cgi?id=46472
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #72 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.21.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla