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

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Thu, 30 Dec 2004, Thomas Sailer wrote: > > No joy with > linux-2.6.10 > patch-2.6.10-ac1 > 01-ptrace-reverse.diff > sigtrap-reverse.diff > > Below is the seh trace output. In the working case (2.6.8) there is no > trace:seh: output at this point. I have no idea what "seh" is in wine-speak, but it appears that your problem is something totally different, especially as none of the eflags- changes seem to matter for you. Also, in your "seh" exception register dump, you don't actually seem to have TF set in %eflags (TF is 0x0100). Some wine person would need to inform us about what the seh exception thing means.. "code c0000005"? Linus

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Wed, 29 Dec 2004, Davide Libenzi wrote: > > That test went in to be able to have ptrace single step, to see even the > instruction following the #int instruction (this was the target of the > patch itself). I just verified that, in 2.6.8 that does not have such test > anymore, the single-step-after-int capability is lost. Ahh. That's because of a separate bug: we have this silly separation of "_TIF_WORK_MASK" (everything but tracing) and "_TIF_ALLWORK_MASK" (everything), and the system call stuff takes over _TIF_SINGLESTEP for some very non-obvious reasons. I don't see why the system-call code thinks _TIF_SINGLESTEP is special, but it certainly explains why it doesn't get handled normally. So the updated patch would look something like the appended. Will test whether it cleanly handles your test-case. Davide - you also added the TIF_SINGLESTEP flag to that _TIF_WORK_MASK, can you explain that? (And yes, I know you'd sent me the test-program before, but I'm about as organized as a Performing Seal with Alzheimers..) Linus --- 1.23/include/asm-i386/thread_info.h 2004-11-18 23:03:11 -08:00 +++ edited/include/asm-i386/thread_info.h 2004-12-29 17:52:16 -08:00 @@ -153,7 +153,7 @@ /* work to do on interrupt/exception return */ #define _TIF_WORK_MASK \ - (0x0000FFFF & ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP)) + (0x0000FFFF & ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT)) #define _TIF_ALLWORK_MASK 0x0000FFFF /* work to do on any return to u-space */ /* --- 1.28/arch/i386/kernel/ptrace.c 2004-11-22 09:44:52 -08:00 +++ edited/arch/i386/kernel/ptrace.c 2004-12-29 17:36:41 -08:00 @@ -568,15 +568,13 @@ audit_syscall_exit(current, regs->eax); } - if (!test_thread_flag(TIF_SYSCALL_TRACE) && - !test_thread_flag(TIF_SINGLESTEP)) + if (!test_thread_flag(TIF_SYSCALL_TRACE)) 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)); + ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) ? 0x80 : 0)); /* * this isn't the same as continuing with a signal, but it will do

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

No joy with linux-2.6.10 patch-2.6.10-ac1 01-ptrace-reverse.diff sigtrap-reverse.diff Below is the seh trace output. In the working case (2.6.8) there is no trace:seh: output at this point. Tom Compiling vhdl file U:/home/sailer/src/vhdl/dvbc_pcseng/vprim.vhd in Library synwork. trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x770e6151 trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=72772078 trace:seh:EXC_RtlRaiseException eax=72772074 ebx=b7a01d9c ecx=7f7daa0c edx=fffffffa esi=7f7499b0 edi=7f7daa0c trace:seh:EXC_RtlRaiseException ebp=77058a70 esp=77ad2150 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210206 trace:seh:EXC_CallHandler calling handler at 0x77134e9f code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x103662d2 code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x1034ec8e code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x4024a0 code=c0000005 flags=0 trace:seh:EXC_RtlUnwind code=c0000005 flags=2 trace:seh:EXC_CallHandler calling handler at 0x77ebe2e0 code=c0000005 flags=2 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x77134e9f code=c0000005 flags=2 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x103662d2 code=c0000005 flags=2 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x1034ec8e code=c0000005 flags=2 trace:seh:EXC_CallHandler handler returned 1 FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com

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, Jesse Allen wrote: > > > > > > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(), > > > can you test whether removing the _testing_ of it in do_syscall_trace() > > > makes things happier for you? Hmm? > > > > > > > Yes, doing that does work. But I still have to remove the conditional > > TF clear. Here's the diff now to show you. > > Ok. That's a good piece of information. > > I don't actually understand why do_syscall_trace() does that > TIF_SINGLESTEP test in the first place, since the ptrace_notify() should > happen as part of the _normal_ TIF_SINGLESTEP handling, afaiks. No > apparent need to do it in syscall tracing, and do_syscall_trace() does > that bogus fake signal sending. > > Hmm.. That TF_SINGLESTEP test was added by Davide Libenzi in August, and I > think Davide had some test for exactly this. Davide? Can you recall why > you did this in the system call tracing code, rather than depend on the > regular TIF_SINGLESTEP handling in arch/i386/kernel/signal.c: > do_notify_resume()? That test went in to be able to have ptrace single step, to see even the instruction following the #int instruction (this was the target of the patch itself). I just verified that, in 2.6.8 that does not have such test anymore, the single-step-after-int capability is lost. Below I inlining a simple test program (that I already sent you time ago) to test this. In my 2.6.8 I get this output: waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485d5 waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485da waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485df waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485d5 waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485da waiting ... done: pid=21398 status=1407 sig=5 EIP=0x080485df in front of this code: 80485d5: b8 14 00 00 00 mov $0x14,%eax 80485da: cd 80 int $0x80 80485dc: 89 45 ec mov %eax,0xffffffec(%ebp) 80485df: eb f4 jmp 80485d5 <main+0x85> You can see that the "mov %eax,0xffffffec(%ebp)" instruction at 0x80485dc is not seen by ptrace single step. With the test in place, it will show up again in your traces. - Davide #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <unistd.h> #include <errno.h> #include <sys/types.h> #include <sys/ptrace.h> #include <sys/wait.h> #include <linux/user.h> #include <linux/unistd.h> int main(int ac, char **av) { int i, status, res; long start, end; pid_t cpid, pid; struct user_regs_struct ur; struct sigaction sa; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = SIG_DFL; sigaction(SIGCHLD, &sa, NULL); printf("nargs=%d\n", ac); if (ac == 1) goto tracer; printf("arg=%s\n", av[1]); loop: __asm__ volatile ("int $0x80" : "=a" (res) : "0" (__NR_getpid)); goto loop; endloop: exit(0); tracer: if ((cpid = fork()) != 0) goto parent; printf("child=%d\n", getpid()); ptrace(PTRACE_TRACEME, 0, NULL, NULL); execl(av[0], av[0], "child", NULL); exit(0); parent: start = (long) &&loop; end = (long) &&endloop; printf("pchild=%d\n", cpid); for (;;) { pid = wait(&status); if (pid != cpid) continue; res = WSTOPSIG(status); if (ptrace(PTRACE_GETREGS, pid, NULL, &ur)) { printf("[%d] error: ptrace(PTRACE_GETREGS, %d)\n", pid, pid); return 1; } if (ptrace(PTRACE_SINGLESTEP, pid, NULL, res != SIGTRAP ? res: 0)) { perror("ptrace(PTRACE_SINGLESTEP)"); return 1; } if (ur.eip >= start && ur.eip <= end) break; } for (i = 0; i < 15; i++) { printf("waiting ...\n"); pid = wait(&status); printf("done: pid=%d status=%d\n", pid, status); if (pid != cpid) continue; res = WSTOPSIG(status); printf("sig=%d\n", res); if (ptrace(PTRACE_GETREGS, pid, NULL, &ur)) { printf("[%d] error: ptrace(PTRACE_GETREGS, %d)\n", pid, pid); return 1; } printf("EIP=0x%08x\n", ur.eip); if (ptrace(PTRACE_SINGLESTEP, pid, NULL, res != SIGTRAP ? res: 0)) { perror("ptrace(PTRACE_SINGLESTEP)"); return 1; } } if (ptrace(PTRACE_CONT, cpid, NULL, SIGKILL)) { perror("ptrace(PTRACE_SINGLESTEP)"); return 1; } return 0; }

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Wed, 29 Dec 2004, Jesse Allen wrote: > > > > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(), > > can you test whether removing the _testing_ of it in do_syscall_trace() > > makes things happier for you? Hmm? > > > > Yes, doing that does work. But I still have to remove the conditional > TF clear. Here's the diff now to show you. Ok. That's a good piece of information. I don't actually understand why do_syscall_trace() does that TIF_SINGLESTEP test in the first place, since the ptrace_notify() should happen as part of the _normal_ TIF_SINGLESTEP handling, afaiks. No apparent need to do it in syscall tracing, and do_syscall_trace() does that bogus fake signal sending. Hmm.. That TF_SINGLESTEP test was added by Davide Libenzi in August, and I think Davide had some test for exactly this. Davide? Can you recall why you did this in the system call tracing code, rather than depend on the regular TIF_SINGLESTEP handling in arch/i386/kernel/signal.c: do_notify_resume()? (Jesse's patch re-appended here in-line for Davide's "reading pleasure"). That still leaves the problem of the clearing of TF_MASK. I _appears_ that the problem is that TF was set both by Wine doing a PTRACE_SINGLESTEP (since PT_DTRACE is set) _and_ the application having TF enabled in eflags from before (since it seems to want to keep it enabled). How about something like the attachment for the TF_MASK issue (replacing your "don't clear" code)? The comments should make the intention pretty obvious, but I have equally obviously not actually _tested_ any of this.. Linus --- --- linux/arch/i386/kernel/ptrace.c 2004-12-29 14:10:34.000000000 -0700 +++ linux-mod/arch/i386/kernel/ptrace.c 2004-12-29 14:22:33.000000000 -0700 @@ -568,8 +568,7 @@ audit_syscall_exit(current, regs->eax); } - if (!test_thread_flag(TIF_SYSCALL_TRACE) && - !test_thread_flag(TIF_SINGLESTEP)) + if (!test_thread_flag(TIF_SYSCALL_TRACE)) return; if (!(current->ptrace & PT_PTRACED)) return; --- linux/arch/i386/kernel/signal.c 2004-12-29 14:10:34.000000000 -0700 +++ linux-mod/arch/i386/kernel/signal.c 2004-12-29 14:23:04.000000000 -0700 @@ -299,8 +299,8 @@ * don't want debugging to change state. */ eflags = regs->eflags; - if (current->ptrace & PT_DTRACE) - eflags &= ~TF_MASK; +// if (current->ptrace & PT_DTRACE) +// eflags &= ~TF_MASK; err |= __put_user(eflags, &sc->eflags); err |= __put_user(regs->esp, &sc->esp_at_signal); err |= __put_user(regs->xss, (unsigned int __user *)&sc->ss);

Dec. 30, 2004

Re: another build problem on current cvs

by Vincent Béron

Le mer 29/12/2004 à 05:38, Joris Huizer a écrit : [snip] > In debian the package is called libasound2-dev, version > "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa I thought we stopped supporting alsa 0.9 a while ago to focus on alsa 1.0... (Looking through dlls/winmm/winealsa/audio.c's changelog, it's been that way since snapshot 20040505). The two versions use the same function names but with different number of args (hence the problems which you saw). Either update to alsa 1.0, downgrade Wine to prior 20040505, or switch to the wineoss driver. Vincent

Dec. 29, 2004

Re: build problem on current cvs

by Stefan Leichter

Am Mittwoch, 29. Dezember 2004 21:26 schrieb Jacek Caban: > Hello. > > >Hello, > > > >this problem confuses me. I have started regession testing. It turn out to > > be a problem of 'out of tree' builds and the name of the directory > > containing the cvs tree. If i use the cvs tree as checked out from winehq > > widl crashes. If i rename the main directory wine of the cvs tree to > > wine-saved1 widl works. It looks like the length of the name makes this > > difference wine-123456 works also. Shorter names crash widl but in > > different files. If i build wine in the cvs tree itself it works too. > > I tried to reproduce a youre situation, but even with the same directory > names widl didn't crash. > > >Logfile of gdb session attached. > > > >Thanks Stefan > > > > > >------------------------------------------------------------------------ > > > >GNU gdb 5.3.92 > >Copyright 2003 Free Software Foundation, Inc. > >GDB is free software, covered by the GNU General Public License, and you > > are welcome to change it and/or distribute copies of it under certain > > conditions. Type "show copying" to see the conditions. > >There is absolutely no warranty for GDB. Type "show warranty" for > > details. This GDB was configured as "i586-suse-linux"... > >(gdb) r > >Starting program: /usr/src/wine/wine-build/tools/widl/widl > > -I../../wine/include -I. -I../../wine/include -I../include -h -H oaidl.h > > ../../wine/include/oaidl.idl > > > >Program received signal SIGSEGV, Segmentation fault. > >0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 > >(gdb) bt > >#0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 > >#1 0x4009d06c in malloc () from /lib/i686/libc.so.6 > >#2 0x080525a0 in pp_xmalloc (size=11) at > > ../../../wine/libs/wpp/preproc.c:80 #3 0x0805264a in pp_xstrdup > > (str=0xbfffec68 "\"11:25:54\"") > > at ../../../wine/libs/wpp/preproc.c:108 > > It is probably caused by overwritting the allocated memory. The last > changes of widl look well so I think it is > some old hidden problem. Lookng at code I found a potential bug, but I'm > not sure if it a bug. In parsers, > both widl's and wpp's, strings are not duplicated whie adding to > structures. If it helps, I'll see if it is correct at all. > This is included in diffs: wppppy.diff and widl.diff. Could you try it? > I also found another small bug in wpp, but > it's not what we're looking for. I included it with some code cleanup in > wpppreproc.diff. > > Thanks, > Jacek Hello Jacek, good shot, applying the three patches fixes my build problem. Many thanks Stefan

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Wed, 29 Dec 2004 12:04:57 -0800 (PST), Linus Torvalds <torvalds(a)osdl.org> wrote: > On Wed, 29 Dec 2004, Jesse Allen wrote: > > > So does removing the conditional TF clear make everything work again? > > > > > > > Yes, as long as TIF_SINGLESTEP is not set in set_singlestep(). > > That may be a clue, if only because that makes absolutely _zero_ sense. > > Setting TIF_SINGLESTEP shouldn't actually matter in this case, since we > set the TRAP_FLAG in eflags by hand anyway (and that's what TIF_SINGESTEP > will just re-do when returning to user space). > > What TIF_SINGLESTEP _does_ do, however, is change how some other issues > are reported to user space. In particular, it causes system call tracing > (see arch/i386/kernel/ptrace.c: do_syscall_trace), and maybe it is _that_ > that messes up Wine. > > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(), > can you test whether removing the _testing_ of it in do_syscall_trace() > makes things happier for you? Hmm? > Yes, doing that does work. But I still have to remove the conditional TF clear. Here's the diff now to show you. Jesse

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Wed, 29 Dec 2004 12:40:53 -0700, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > For the wine people, I will try to upload the seh debug channel logs > as soon as possible. > I have a page with the latest logs. http://www.chez.com/alors/

Dec. 29, 2004

Re: build problem on current cvs

by Jacek Caban

Hello. >Hello, > >this problem confuses me. I have started regession testing. It turn out to be >a problem of 'out of tree' builds and the name of the directory containing >the cvs tree. If i use the cvs tree as checked out from winehq widl crashes. >If i rename the main directory wine of the cvs tree to wine-saved1 widl >works. It looks like the length of the name makes this difference wine-123456 >works also. Shorter names crash widl but in different files. If i build wine >in the cvs tree itself it works too. > > > I tried to reproduce a youre situation, but even with the same directory names widl didn't crash. >Logfile of gdb session attached. > >Thanks Stefan > > >------------------------------------------------------------------------ > >GNU gdb 5.3.92 >Copyright 2003 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "i586-suse-linux"... >(gdb) r >Starting program: /usr/src/wine/wine-build/tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include -h -H oaidl.h ../../wine/include/oaidl.idl > >Program received signal SIGSEGV, Segmentation fault. >0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >(gdb) bt >#0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >#1 0x4009d06c in malloc () from /lib/i686/libc.so.6 >#2 0x080525a0 in pp_xmalloc (size=11) at ../../../wine/libs/wpp/preproc.c:80 >#3 0x0805264a in pp_xstrdup (str=0xbfffec68 "\"11:25:54\"") > at ../../../wine/libs/wpp/preproc.c:108 > > It is probably caused by overwritting the allocated memory. The last changes of widl look well so I think it is some old hidden problem. Lookng at code I found a potential bug, but I'm not sure if it a bug. In parsers, both widl's and wpp's, strings are not duplicated whie adding to structures. If it helps, I'll see if it is correct at all. This is included in diffs: wppppy.diff and widl.diff. Could you try it? I also found another small bug in wpp, but it's not what we're looking for. I included it with some code cleanup in wpppreproc.diff. Thanks, Jacek

Dec. 29, 2004