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.