December 2004 - Wine-Devel - list.winehq.org

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Lionel Ulmer

> Word on the street is that we need an implementation of the DirectDraw > clipper, but I have no idea if that's correct or if so, how much of it we > need. Last time I checked, it was not clipper related at all. It's basically (from what I remember - I could be wrong) QuickTime that displays on the desktop window using DirectX (just at the start, after it uses clipper and windows). This means that if we want to make this work, we need first to lock the X server then take a screenshot of the root window then put it in the buffer to give back to QT to draw on it and then re-copy this in what is currently the black window and finally unlock the X server... In other means a bad hack :-) In my opinion, the cleanest would just to not support at all 'window-less' DirectX as the only one using it is QT and it uses it badly :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Thu, 30 Dec 2004 09:59:27 -0800 (PST), Davide Libenzi <davidel(a)xmailserver.org> wrote: > On Wed, 29 Dec 2004, Linus Torvalds wrote: > > > On Wed, 29 Dec 2004, Davide Libenzi wrote: > > > > > > I think same. My test simply let the function processing to let thru and > > > reach the fake signal sending point. > > > > No, your test-case doesn't even send a signal at all, because your > > test-program just uses a PTRACE_SINGLESTEP without any "send signal" - so > > "exit_code" will be zero after the debuggee gets released from the > > "ptrace_notify()", and the suspect code will never be executed.. > > No no, my test case has nothing to do with the extra signal sent in > do_syscall_trace(). But the test I put at the time: > > - if (!test_thread_flag(TIF_SYSCALL_TRACE)) > + if (!test_thread_flag(TIF_SYSCALL_TRACE) && > + !test_thread_flag(TIF_SINGLESTEP)) > return; > > will make the code to not execute the "return" (in the single step case) > and to fall through the point where the signal is sent. Using the latest version of the patch on do_syscall_trace(), it still doesn't work unless I remove this test. If indeed it's supposed to fall through to receive the proper signal, (ie to single step properly after an int op), then removing it is wrong, and I won't consider it anymore. I also have to use the patch shown below, with a typo-fixed, to fix the other problem. I broke it apart from the other because we might want to consider it seperately right now. I spent some time speaking to my brother about this. He has done his own kernel before for an embedded system. He was rather frustrated with me trying to find a reason for why a rather simple change broke my program. He told me I couldn't have it both ways. However I believe that I don't understand the linux code well enough to make that conclusion. > > > > The problem I think I see (and which the comment alludes to) is that if > > the controlling process continues the debuggee with a signal, we'll be > > doing the wrong thing: the code in do_syscall_trace() will take that > > signal (in "current->exit_code") and send it as a real signal to the > > debuggee, but since it is debugged, it will be caught (again) by the > > controlling process, which apparently in the case of Wine gets very > > confused. > > > > So I _think_ the problem happens for the following schenario: > > - wine for some reason does a PTRACE_SINGLESTEP over a system call > > - after the single-step, wine ends up trying to get the sub-process to > > enter a signal handler with ptrace( PTRACE_CONT, ... sig) > > - the normal ptrace path (where we trap a signal - see kernel/signal.c > > and the "ptrace_stop()" logic) handles this correctly, but > > do_syscall_trace() will do a "send_sig()" > > - we'll try to handle the signal when returning to the traced process > > - now "get_signal_to_deliver()" will invoce the ptrace logic AGAIN, and > > call ptrace_stop() for this fake signal, and we'll report a new event > > to the controlling process. > > > > Does this make sense? > > This might explain what they were seeing, but OTOH it seems that the real > cause of their problems is related to something else (according to other > emails on this thread). > > Actually, I don't think the vanilla kernel has the code that breaks those other wine programs. I just learned of this yesterday and it's not related. I believe it's only in fedora core 3 or -ac kernels and I use vanilla kernels. Jesse --- linux/arch/i386/kernel/ptrace.c 2004-12-29 14:10:34.000000000 -0700 +++ linux-mod/arch/i386/kernel/ptrace.c 2004-12-29 20:50:00.000000000 -0700 @@ -142,18 +142,31 @@ { long eflags; + /* + * Always set TIF_SINGLESTEP - this guarantees that + * we single-step system calls etc.. + */ set_tsk_thread_flag(child, TIF_SINGLESTEP); + + /* + * If TF was already set, don't do anything else + */ eflags = get_stack_long(child, EFL_OFFSET); + if (eflags & TRAP_FLAG) + return; put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG); child->ptrace |= PT_DTRACE; } static void clear_singlestep(struct task_struct *child) { + /* Always clear TIF_SINGLESTEP... */ + clear_tsk_thread_flag(child, TIF_SINGLESTEP); + + /* But touch TF only if it was set by us.. */ if (child->ptrace & PT_DTRACE) { long eflags; - clear_tsk_thread_flag(child, TIF_SINGLESTEP); eflags = get_stack_long(child, EFL_OFFSET); put_stack_long(child, EFL_OFFSET, eflags & ~TRAP_FLAG); child->ptrace &= ~PT_DTRACE;

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Davide Libenzi

On Wed, 29 Dec 2004, Linus Torvalds wrote: > On Wed, 29 Dec 2004, Davide Libenzi wrote: > > > > I think same. My test simply let the function processing to let thru and > > reach the fake signal sending point. > > No, your test-case doesn't even send a signal at all, because your > test-program just uses a PTRACE_SINGLESTEP without any "send signal" - so > "exit_code" will be zero after the debuggee gets released from the > "ptrace_notify()", and the suspect code will never be executed.. > > The problem I think I see (and which the comment alludes to) is that if > the controlling process continues the debuggee with a signal, we'll be > doing the wrong thing: the code in do_syscall_trace() will take that > signal (in "current->exit_code") and send it as a real signal to the > debuggee, but since it is debugged, it will be caught (again) by the > controlling process, which apparently in the case of Wine gets very > confused. > > So I _think_ the problem happens for the following schenario: > - wine for some reason does a PTRACE_SINGLESTEP over a system call > - after the single-step, wine ends up trying to get the sub-process to > enter a signal handler with ptrace( PTRACE_CONT, ... sig) > - the normal ptrace path (where we trap a signal - see kernel/signal.c > and the "ptrace_stop()" logic) handles this correctly, but > do_syscall_trace() will do a "send_sig()" > - we'll try to handle the signal when returning to the traced process > - now "get_signal_to_deliver()" will invoce the ptrace logic AGAIN, and > call ptrace_stop() for this fake signal, and we'll report a new event > to the controlling process. Make sense to me. What about the one below? The problem is though, that we have two different events here. One is the single step trap and the other one is the signal. And according to the comment, strace want something different from SIGTRAP to continue with signal. So it wants the double event we are actually sending (ptrace_notify + send_sig). OTOH Wine does not seem to like the double event thingy. Hmm ...? - Davide --- ptrace.c.orig 2004-12-30 10:29:11.000000000 -0800 +++ ptrace.c 2004-12-30 11:11:23.000000000 -0800 @@ -573,18 +573,14 @@ return; if (!(current->ptrace & PT_PTRACED)) return; - /* the 0x80 provides a way for the tracing parent to distinguish - between a syscall stop and SIGTRAP delivery */ - ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) && - !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0)); - /* - * this isn't the same as continuing with a signal, but it will do - * for normal use. strace only continues with a signal if the - * stopping signal is not SIGTRAP. -brl - */ if (current->exit_code) { - send_sig(current->exit_code, current, 1); + ptrace_notify(current->exit_code); current->exit_code = 0; + } else { + /* the 0x80 provides a way for the tracing parent to distinguish + between a syscall stop and SIGTRAP delivery */ + ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) && + !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 0)); } }

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Thu, 30 Dec 2004, Davide Libenzi wrote: > > This might explain what they were seeing, but OTOH it seems that the real > cause of their problems is related to something else (according to other > emails on this thread). There's two different problems: the one seen by Thomas (the Xilinx FPGA synthesizer), which is apparently just due to Wine (or, more likely, the Windows app itself) depending on a certain memory layout for the stack and/or other allocations. That one I think we can consider solved, and indeed had nothing to do with TF. The other one is the copy-protection code breaking for some game (Warcraft) for Jesse Allen, and that one is definitely TF-related.. Jesse can fix it with patches, but those patches aren't acceptable for other uses, so that's why I'm trying to find something that DTRT both for Wine and for a regular debugging session.. Linus

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Davide Libenzi

On Wed, 29 Dec 2004, Linus Torvalds wrote: > On Wed, 29 Dec 2004, Davide Libenzi wrote: > > > > I think same. My test simply let the function processing to let thru and > > reach the fake signal sending point. > > No, your test-case doesn't even send a signal at all, because your > test-program just uses a PTRACE_SINGLESTEP without any "send signal" - so > "exit_code" will be zero after the debuggee gets released from the > "ptrace_notify()", and the suspect code will never be executed.. No no, my test case has nothing to do with the extra signal sent in do_syscall_trace(). But the test I put at the time: - if (!test_thread_flag(TIF_SYSCALL_TRACE)) + if (!test_thread_flag(TIF_SYSCALL_TRACE) && + !test_thread_flag(TIF_SINGLESTEP)) return; will make the code to not execute the "return" (in the single step case) and to fall through the point where the signal is sent. > The problem I think I see (and which the comment alludes to) is that if > the controlling process continues the debuggee with a signal, we'll be > doing the wrong thing: the code in do_syscall_trace() will take that > signal (in "current->exit_code") and send it as a real signal to the > debuggee, but since it is debugged, it will be caught (again) by the > controlling process, which apparently in the case of Wine gets very > confused. > > So I _think_ the problem happens for the following schenario: > - wine for some reason does a PTRACE_SINGLESTEP over a system call > - after the single-step, wine ends up trying to get the sub-process to > enter a signal handler with ptrace( PTRACE_CONT, ... sig) > - the normal ptrace path (where we trap a signal - see kernel/signal.c > and the "ptrace_stop()" logic) handles this correctly, but > do_syscall_trace() will do a "send_sig()" > - we'll try to handle the signal when returning to the traced process > - now "get_signal_to_deliver()" will invoce the ptrace logic AGAIN, and > call ptrace_stop() for this fake signal, and we'll report a new event > to the controlling process. > > Does this make sense? This might explain what they were seeing, but OTOH it seems that the real cause of their problems is related to something else (according to other emails on this thread). - Davide

Dec. 30, 2004

Re: Looking for Software which uses the MS Crypto API

by Jesse Allen

On Thu, 30 Dec 2004 17:50:09 +0100, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Hello, > > In order to test rsaenh.dll, I'm looking for software, which applies the > Microsoft Crypto-API. Any suggestions? It would be ideal, if the source is > available. > > Ciao, > Michael > > Blizzard's game patching software seems to use it to authenticate the patch archive. Your changes broke the patcher: "unable to authenticate", last time I checked, but I am unable to update to the current cvs at the moment. No source, sorry. I'll check up on it at a later time.

Dec. 30, 2004

Re: Get rid of DPRINTF in wininet

by Diego 'Flameeyes' Pettenò

On Thursday 30 December 2004 17:15, Dimitrie O. Paun wrote: > I'm afraid it is <g>. This is a case where the wine_dbg_sprintf() > business is in order. This time at least I know what I did wrong ^^ I'll fix these up as soon as I understand how wine_dbg_sprintf() works :) -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Dec. 30, 2004

Looking for Software which uses the MS Crypto API

by Michael Jung

Hello, In order to test rsaenh.dll, I'm looking for software, which applies the Microsoft Crypto-API. Any suggestions? It would be ideal, if the source is available. Ciao, Michael

Dec. 30, 2004

Re: Get rid of DPRINTF in opengl32

by Dimitrie O. Paun

On Thu, Dec 30, 2004 at 12:37:12PM +0100, Diego 'Flameeyes' Pettenò wrote: > Hi, > this time is a very small patch, it simply replace DPRINTF with TRACE without > oher changes. Once again, a job for wine_dbg_sprintf(). -- Dimi.

Dec. 30, 2004

Re: Get rid of DPRINTF in wininet

by Dimitrie O. Paun

On Thu, Dec 30, 2004 at 12:33:52PM +0100, Diego 'Flameeyes' Pettenò wrote: > I hope only my usual karma is not here this time or I'll make everybody lost > time ^^ I'm afraid it is <g>. This is a case where the wine_dbg_sprintf() business is in order. -- Dimi.

Dec. 30, 2004