Kernel 2.6.9 - Issue Found
Hi, For the past two weeks I've been tracking an issue that I found with kernels greater than 2.6.8 / 2.6.8.1 and wine. Starting with kernel 2.6.9-rc1, Warcraft III copy protection would not work -- ie please insert disc. I found changes to the cdrom driver in rc1. Reversing them did not work. For a while I was lost to what could have changed. Then I had an idea: search for changes that could affect the way processes run. That led me to reverse changes related to ptrace, and I found a series of patches that break Warcraft III copy protection code. Patch 1: ptrace single-stepping fix Included in 2.6.9-rc1 By Davide Libenzi? http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.1803.144.55 This change includes a note that it could break debuggers. Reversing this change would allow War3 to work in rc1, but kernels greater than rc1 would still not work. Patch 2: make single-step into signal delivery stop in handler Included in 2.6.9-rc2 By Roland McGrath http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1832.59.196 The next patch may depend on patch #2 because it is a bug-fix based on 2. Patch 3: Fix PTRACE_CONT after single-step into signal delivery Also 2.6.9-rc2 By Roland McGrath http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1847 Reversing patches 1, 2, and 3 in kernels 2.6.9-rc2 and greater (through 2.6.10-rc1) will allow War3 to work. I tried 1 & 3 without 2, but it failed leading me to believe that 1 & 2 are required. I didn't try 1 & 2 alone because I think reversing 2 would require 3 reversed. All the patch changes seem to be on ptrace single-stepping. However, there is at least one ptrace single-stepping patch that seems to make no difference at all: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.70 There are other single-stepping patches for different non-i386 architectures but I have no idea on these because I don't run the others. They are meaningless for wine anyways. Now that I've identified a problem, I'm curious where else it's cropping up. Paul Rupe, could you try reversing these patches to see if this fixes your crashing problem? And how about those people having trouble with debugging? Then I guess the next step is to find out if this is a wine bug or not. If it's not, then it may be a kernel bug and we should report it to the kernel devs. Jesse
On Sat, Nov 13, 2004 at 05:23:19PM -0700, Jesse Allen wrote:
Patch 1: ptrace single-stepping fix Included in 2.6.9-rc1 By Davide Libenzi?
corrected link: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.55
Jesse Allen a écrit :
On Sat, Nov 13, 2004 at 05:23:19PM -0700, Jesse Allen wrote:
Patch 1: ptrace single-stepping fix Included in 2.6.9-rc1 By Davide Libenzi?
corrected link: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.55
This shall harm us... Basically, when a program is traced by ptrace, and single stepping, the patches allow to also single step in the program's SIGTRAP handler... In Wine case: - the handler is wine's implementation to send the single step event to wineserver - our code implies that the handler is not seen from wineserver (basically, that after executing the single step, the debugging event is sent to wine server) To sum up, it's not a wine bug nor a linux bug, it's just a change in linux behavior that breaks wine. Linux new approach is to say a signal handler is part of the application, and should be traced (in a debugger for example) as a regular function. Wine sees signal handler (at least SIGTRAP, SIGSEGV...) as kernel plugs put in the application (NTDLL) and used to send back information to Wine server. Those two options are not compatible. IMO, the best option would be to add an option to turn on/off the behavior in ptrace (to allow or not single stepping in signal handlers). Fixing Wine would be doable, but somehow ugly (ie it would mean turning the TF off in Wine server to let our handlers run...) A+
On Sat, Nov 13, 2004 at 05:35:43PM -0700, Jesse Allen wrote:
On Sat, Nov 13, 2004 at 05:23:19PM -0700, Jesse Allen wrote:
Patch 1: ptrace single-stepping fix Included in 2.6.9-rc1 By Davide Libenzi?
corrected link: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.55
Davide Libenzi wrote this about his patch and concerning the small note about breaking debuggers: 'If the "debugger" has a bolt-in rule to expect the instruction following the INT# to be skipped, yes. As far as debuggers that are really used goes, it did not break any of them. If this copy protection for example, has a bolt-in instruction sequence that expect the instruction following INT# to be skipped, than I believe they should code it better. Patch 1 does simply enable the debugger to see every instruction to the ptrace'r. While before the instruction following INT# were silently skipped.'
On Saturday November 13 2004 07:23 pm, Jesse Allen wrote:
Now that I've identified a problem, I'm curious where else it's cropping up. Paul Rupe, could you try reversing these patches to see if this fixes your crashing problem? And how about those people having trouble with debugging?
Thanks, I'll try that out Monday when I can test it with Remedy again. I had hoped to find some other app that would break this way, but no luck so far. -- Paul Rupe <prupe(a)myrealbox.com>
participants (4)
-
Eric Pouech -
Jesse Allen -
Mike Hearn -
Paul Rupe