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

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

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. Does this make sense? If so, we have a few options: - very hacky one: teach all ptrace users that sometimes the signal you continue with can be reflected back at you, and you should just "cont signr" _again_. This is a really bad option, partly because it's hard to tell when it's just a spurious reflected signal, partly because there are many ptrace users, and to a large part just because it's clearly too hacky. But it might be a valid approach for a Wine person who is used to Wine, and wants to verify whether this is indeed the schenario that triggers the problem.. - Stupid approach: mark the siginfo that we send as the fake one as being reflected, and have get_signal_to_deliver() not apply the ptrace stopping to that. - Possibly cleaner approach: make system call tracing just use a proper SIGTRAP in the first place, and always handle all the ptrace_stop() etc cruft in kernel/signal.c like it handles all other calls. I dunno. The final one looks fairly simple and clean, something like the following, but I'm most likely overlooking some reason why this won't work.. (And as usual, this patch has not been tested in any shape, way or form. In fact, it hasn't even seen an x86 machine, since I edited it out as a fake on my ppc64.. Somebody with more brains than me should actually try to get it to work) Linus ---- ===== arch/i386/kernel/ptrace.c 1.28 vs edited ===== --- 1.28/arch/i386/kernel/ptrace.c 2004-11-22 09:44:52 -08:00 +++ edited/arch/i386/kernel/ptrace.c 2004-12-29 23:21:58 -08:00 @@ -559,6 +559,8 @@ __attribute__((regparm(3))) void do_syscall_trace(struct pt_regs *regs, int entryexit) { + struct siginfo info; + if (unlikely(current->audit_context)) { if (!entryexit) audit_syscall_entry(current, regs->orig_eax, @@ -573,18 +575,18 @@ return; if (!(current->ptrace & PT_PTRACED)) return; + + memset(&info, 0, sizeof(info)); + info.si_signo = SIGTRAP; + /* 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)); + info.si_code = SIGTRAP; + if ((current->ptrace & PT_TRACESYSGOOD) && !test_thread_flag(TIF_SINGLESTEP)) + info.si_code = SIGTRAP | 0x80; + info.si_pid = current->tgid; + info.si_uid = current->uid; - /* - * 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); - current->exit_code = 0; - } + /* Send us the fakey SIGTRAP */ + send_sig_info(SIGTRAP, &info, current); }

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, Linus Torvalds wrote: > > > > .. no, I see what's up. System call returns _are_ special for > > single-stepping. I'll think about it.. > > Ok, I think I know what's up. > > It's literally the bogus fake signal that do_syscall_trace() sends. I > think the TIF_SINGLESTEP case in do_syscall_trace() should only do the > ptrace_notify() and return.. I think same. My test simply let the function processing to let thru and reach the fake signal sending point. - Davide

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Davide Libenzi

On Wed, 29 Dec 2004, Linus Torvalds wrote: > 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? I honestly do not remember, but I think is wrong and can be removed. That's not the problem though ... - Davide

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Wed, 29 Dec 2004, Linus Torvalds wrote: > > .. no, I see what's up. System call returns _are_ special for > single-stepping. I'll think about it.. Ok, I think I know what's up. It's literally the bogus fake signal that do_syscall_trace() sends. I think the TIF_SINGLESTEP case in do_syscall_trace() should only do the ptrace_notify() and return.. Linus

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Wed, 29 Dec 2004, Linus Torvalds wrote: > > So the updated patch would look something like the appended. .. no, I see what's up. System call returns _are_ special for single-stepping. I'll think about it.. Linus

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Wed, 29 Dec 2004 16:44:05 -0800 (PST), Linus Torvalds <torvalds(a)osdl.org> wrote: > > 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.. > The following patch works for me. I still have to remove TIF_SINGLESTEP test. I also went ahead and tried adding the other fix on the ptrace_notify call and _TIF_WORK_MASK, but for some reason, changing _TIF_WORK_MASK seems to break the program now. This patch does fix the TF clearing problem. 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; @@ -568,15 +581,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 Andrew Morton

Thomas Sailer <sailer(a)scs.ch> wrote: > > Another pointer towards flexible mmap is that ulimit -s unlimited makes > it work under 2.6.10-ac1 too. > You can globally disable flex-mmap with echo 1 > /proc/sys/vm/legacy_va_layout Does it fix things?

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

Another pointer towards flexible mmap is that ulimit -s unlimited makes it work under 2.6.10-ac1 too. Tom

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

On Wed, 2004-12-29 at 18:10 -0800, Linus Torvalds wrote: > Some wine person would need to inform us about what the seh exception > thing means.. "code c0000005"? There's an interesting thing. Fedora Kernel 2.6.7 works for me, Fedora Kernel 2.6.8 breaks wine/xst. Interestingly, Linus 2.6.8 works. Now the biggest changes between the Fedora Kernels 2.6.7-1.494.2.2 and 2.6.8-1.521, besides the rebasing, are some execshield changes and flexible mmap. execshield cannot be the culprit as it's not in 2.6.10- ac1, but flexible mmap seems to be in 2.6.10-ac1. To me, a candidate for further scrutiny is flexmmap, although I do not claim to have a clue about linux-mm... Tom

Dec. 30, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

On Wed, 2004-12-29 at 18:10 -0800, Linus Torvalds wrote: > I have no idea what "seh" is in wine-speak, but it appears that your seh means structured exception handling in microsoft-speak. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base… http://www.jorgon.freeserve.co.uk/ExceptFrame.htm > Some wine person would need to inform us about what the seh exception > thing means.. "code c0000005"? c0000005 apparently means memory access violation. Looks like xst is getting confused about its memory allocations... Tom

Dec. 30, 2004

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

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Wed, 29 Dec 2004 20:35:44 +0100, Thomas Sailer <sailer(a)scs.ch> wrote: > > Mike, > > thanks a lot for your mail. I've just tried Jesse Allen's Patch with > 2.6.10-ac1, but unfortunately it doesn't seem to be enough to get xst > working again. Let me know if (and how :)) I can help gather evidence. > > Tom > > If the single-stepping changes truly broke your program, and you know < 2.6.9-rc1 works, try this attached diff against 2.6.10 in addition to the other one I made. This should effectively reverse change #2, but like I said, the current code for change #2 actually works for me now. But maybe this is not enough. You can also look here at my original report: http://www.winehq.org/hypermail/wine-devel/2004/11/0310.html and reverse the original patches against 2.6.9, and see if that kernel works then. Patch links: http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1803.144.55 http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1832.60.196 http://linux.bkbits.net:8080/linux-2.6/cset(a)1.1847 Jesse

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

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? (Also, looking at the code, I get the feeling that set_singlestep() should _only_ set TIF_SINGLESTEP, and not set the TRAP_FLAG by hand at all, since TIF_SINGESTEP should take care of that detail regardless). Linus

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Jesse Allen

On Wed, 29 Dec 2004 10:53:54 -0800 (PST), Linus Torvalds <torvalds(a)osdl.org> wrote: > Ok, I don't remember the context from the Wine lists (and it's not clear > from the older emails I was cc'd on), so the "#3 signal.c" change > description is a bit too vague. Jesse, willing to just point to the exact > diff that you need to make Warcraft work for you (and then maybe Thomas > Sailer can verify whether that part is indeed the one that causes him > problems). I have attached the diff attached in this message for the lkml. > > The code in question now does > > /* > * Iff TF was set because the program is being single-stepped by a > * debugger, don't save that information on the signal stack.. We > * don't want debugging to change state. > */ > eflags = regs->eflags; > if (current->ptrace & PT_DTRACE) > eflags &= ~TF_MASK; > err |= __put_user(eflags, &sc->eflags); > > and I guess it originally never cleared it. True? Yes. > > So does removing the conditional TF clear make everything work again? > Yes, as long as TIF_SINGLESTEP is not set in set_singlestep(). set_singlestep also sets PT_DTRACE, so as it now is, a call to the set_singlestep function will make this condition true clearing TF when run. So both the conditional TF clear and setting TIF_SINGLESTEP needs to be removed, like I show in the diff. Making these changes returns the code to a 2.6.8-ish resemblence. For the wine people, I will try to upload the seh debug channel logs as soon as possible. Jesse

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

On Wed, 2004-12-29 at 15:02 +0000, Mike Hearn wrote: Mike, thanks a lot for your mail. I've just tried Jesse Allen's Patch with 2.6.10-ac1, but unfortunately it doesn't seem to be enough to get xst working again. Let me know if (and how :)) I can help gather evidence. Tom

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Linus Torvalds

On Wed, 29 Dec 2004, Mike Hearn wrote: > > I can't see if he CCd anybody from the archives but Jesse Allen posted a > nice analysis of the remaining problem here: > > http://www.winehq.org/hypermail/wine-devel/2004/12/0691.html Ok, I don't remember the context from the Wine lists (and it's not clear from the older emails I was cc'd on), so the "#3 signal.c" change description is a bit too vague. Jesse, willing to just point to the exact diff that you need to make Warcraft work for you (and then maybe Thomas Sailer can verify whether that part is indeed the one that causes him problems). The code in question now does /* * Iff TF was set because the program is being single-stepped by a * debugger, don't save that information on the signal stack.. We * don't want debugging to change state. */ eflags = regs->eflags; if (current->ptrace & PT_DTRACE) eflags &= ~TF_MASK; err |= __put_user(eflags, &sc->eflags); and I guess it originally never cleared it. True? So does removing the conditional TF clear make everything work again? Linus

Dec. 29, 2004

Re: clean-up

by Eric Blade

My apologies for not responding, I had attempted to sign up for the list, and that had failed. Oops! Now, here I am. :) Paul van Schayck said, about the <<br />> .. oops, that was a mistake in my search/replace.. I thought I had fixed all of those occurences that I made. Also, for the !loggedin() || !have_priv(admin) .. i just copied that code from another module, that had used it in that exact same spot.. the file had a comment that said "// check for admin access here" .. :P no, i don't think it should be !loggedin() && !have_priv(admin) .. that wouldn't make sense, if it were &&.. that needs to be an || . Re: Johnathan Ernst: As I said, I had just copied the code from the other places in the admin/* files that used it. Before I changed that, the code simply said: if(!loggedin()) .. which meant anyone logged in could access that admin function. It does make sense that if not logged in you couldn't have admin privs, so I could change all the files to check that instead. So, my next question.. do you have to have admin priv to be a maintainer? Becauses some of the files check for loggedin, havepriv(admin) and maintainer flags. Should admin/adminCommentView.php be protected? I realise it's in the admin category, but it doesn't look like anyone can get into any mischief with that.. could almost be handy for users. --- anyway, i've fixed those issues, merged it to latest CVS, and will be re-sending it off in just a minute. Thanks :) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 29, 2004

Re: [AppDB] Small appbrowse cleanup

by Chris Morgan

Please, no tabs :-P Chris On Wednesday 29 December 2004 7:10 am, Paul van Schayck wrote: > weird

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Mike Hearn

On Wed, 2004-12-29 at 03:14 +0100, Thomas Sailer wrote: > Any news about the ptrace single-stepping breakage of wine? I can't see if he CCd anybody from the archives but Jesse Allen posted a nice analysis of the remaining problem here: http://www.winehq.org/hypermail/wine-devel/2004/12/0691.html Here is one interesting portion of his email: > #3 signal.c - Clearing the trap flag if being traced by debugger in > setup_sigcontext() > > For some reason, Warcraft III doesn't work if it is cleared here. I > have no idea if this TF clear is really necessary. However, > everything I've read on this seems to indicate to me that this change > is important, so I need to find out what this causes to the game. The other changes Linus made are apparently good and do not cause Warcraft to regress. thanks -mike

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >>> >>>> >>>> @@ -1191,7 +1287,9 @@ >>>> OAFilterState *pfs) { >>>> ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >>>> >>>> - TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, >>>> msTimeout, pfs); >>>> + TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, >>>> msTimeout, pfs); >>>> + >>>> + *pfs = This->state; >>>> >>>> >>>> >>> >>> This probably needs protection too. >>> >> >> I saw you also did this for filesource and avi splitter filters. >> What do you want to prevent here? > > > > Partial updates and potential code that depends on the state not > changing in a function. I was thinking about something like that but was not sure. Thanks. :-) Bye, Christian

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph (take 2)

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Hi, >> >> This time with more thread safety. > > > > Looking better, but one more change needed. In addition, most of the > code in filtergraph.c isn't thread safe. I agree. I will look at this after I finish what I'm currently working on. > Thread safety is particularly important in DirectShow where threads > are heavily used. Debugging random crashes is not fun. Bye, Christian

Dec. 29, 2004

Re: build problem on current cvs

by Michael Stefaniuc

Stefan Leichter wrote: > 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'm doing only out of tree builds and my source directories are named wine. But my path to those wine directories are longer than yours. One is an absolute path (different file systems) the other two directory layers more then yours (-I../../../source/wine/include). I never encountered a crash. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Christian Costa

> >> >> @@ -1191,7 +1287,9 @@ >> OAFilterState *pfs) { >> ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >> >> - TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, >> pfs); >> + TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, >> msTimeout, pfs); >> + >> + *pfs = This->state; >> >> >> > > This probably needs protection too. > I saw you also did this for filesource and avi splitter filters. What do you want to prevent here? Bye, Christian

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph (take 2)

by Robert Shearman

Christian Costa wrote: > Hi, > > This time with more thread safety. Looking better, but one more change needed. In addition, most of the code in filtergraph.c isn't thread safe. Thread safety is particularly important in DirectShow where threads are heavily used. Debugging random crashes is not fun. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); >+ >+ if (This->state == State_Running) >+ return S_OK; > > > This should be inside the critical section, being careful, of course, not to return without calling LeaveCriticalSection. >+ EnterCriticalSection(&This->cs); >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ >+ LeaveCriticalSection(&This->cs); >+ > return S_FALSE; > } > > Rob

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Robert Shearman

Christian Costa wrote: >> >>> >>> @@ -1191,7 +1287,9 @@ >>> OAFilterState *pfs) { >>> ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >>> >>> - TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, >>> pfs); >>> + TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, >>> msTimeout, pfs); >>> + >>> + *pfs = This->state; >>> >>> >>> >> >> This probably needs protection too. >> > > I saw you also did this for filesource and avi splitter filters. > What do you want to prevent here? Partial updates and potential code that depends on the state not changing in a function. Rob

Dec. 29, 2004

Re: another build problem on current cvs

by Joris Huizer

Vincent Béron wrote: > Le mar 28/12/2004 à 09:24, Joris Huizer a écrit : > >>Hello, >> >>For the past week or so, building from cvs on a debian/stable system w/ >>alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks >>on alsa-specific code in wine; >>I attached the log; note that I did a `cvs update -dPA` and `make >>distclean` so this can't be any problem with the source I have >> >>Any ideas? Maybe you can point me to a place where I can read how to fix >>this properly (I never worked on alsa-specific code before...) or >>something like that > > > Which version of ALSA do you have headers for? > > Vincent > > > > In debian the package is called libasound2-dev, version "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa Joris

Dec. 29, 2004

Re: build problem on current cvs

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 23:47 schrieb Jacek Caban: > Stefan Leichter wrote: > >Am Dienstag, 28. Dezember 2004 11:15 schrieb Jacek Caban: > >>Hi. > >> > >>Stefan Leichter wrote: > >>>Hello, > >>> > >>>i hope you all had nice Christmas. > >>> > >>>Now back to business :-) > >>> > >>>trying to build current cvs (~7:45 AM UTC) i get the error: > >>> > >>>make[1]: Entering directory `/usr/src/wine/wine-build/include' > >>>../tools/widl/widl -I../../wine/include -I. -I../../wine/include > >>>-I../include -h -H oaidl.h ../../wine/include/oaidl.idl > >>> > >>> > >>>../../wine/include/wtypes.idl:1: Oops, segment violation > >>>make[1]: *** [oaidl.h] Abgebrochen > >>>make[1]: *** Datei »oaidl.h« wird gelöscht > >>>make[1]: Leaving directory `/usr/src/wine/wine-build/include' > >>>make: *** [include] Fehler 2 > >>> > >>>My system is still SuSE 9.0. I am doing 'out of tree' builds. > >>> > >>>Bye Stefan > >> > >>Did you do make depend? > >> > >>Thanks, > >> Jacek > > > >this happens for me during make depend ;-) > > > >Thanks Stefan > > Could you try debug widl by gdb? Try: > $ gdb --args ../tools/widl/widl -I../../wine/include -I. > -I../../wine/include -I../include -h -H oaidl.h > ../../wine/include/oaidl.idl 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. Logfile of gdb session attached. Thanks Stefan

Dec. 29, 2004

Re: [QUARTZ] Some stuff to start the graph

by Robert Shearman

Christian Costa wrote: > Hi, > > Changelog: > Implemented IMediaControl_Run that explores the graph, counts > renderers and starts filters. > Better implementation of IBaseFilter_Run for AVI SPlitter and AVI > Decompressor. > Use the standard memory allocator when an output pin does not provide > any allocator. > Set allocator properties for AVI Decompressor output pin and update > the buffers size at connection time. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: dlls/quartz/avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.12 >diff -u -r1.12 avidec.c >--- dlls/quartz/avidec.c 27 Dec 2004 17:15:58 -0000 1.12 >+++ dlls/quartz/avidec.c 29 Dec 2004 09:06:24 -0000 >@@ -235,6 +235,9 @@ > pAVIDec->pBihOut->biCompression = 0; > pAVIDec->pBihOut->biSizeImage = pAVIDec->pBihOut->biWidth * pAVIDec->pBihOut->biHeight * pAVIDec->pBihOut->biBitCount / 8; > >+ /* Update buffer size of media samples in output */ >+ ((OutputPin*)pAVIDec->ppPins[1])->allocProps.cbBuffer = pAVIDec->pBihOut->biSizeImage; >+ > pAVIDec->init = 1; > TRACE("Connection accepted\n"); > return S_OK; >@@ -354,7 +357,13 @@ > > if (SUCCEEDED(hr)) > { >- hr = AVIDec_OutputPin_Construct(&piOutput, NULL, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); >+ ALLOCATOR_PROPERTIES props; >+ props.cbAlign = 1; >+ props.cbPrefix = 0; >+ props.cbBuffer = 0; /* Will be updated at connection time */ >+ props.cBuffers = 2; >+ >+ hr = AVIDec_OutputPin_Construct(&piOutput, &props, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); > > if (FAILED(hr)) > ERR("Cannot create output pin (%lx)\n", hr); >@@ -502,6 +511,8 @@ > This->state = State_Running; > } > LeaveCriticalSection(&This->csFilter); >+ >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[1]); > > This needs to be inside the critical section. > > return hr; > } >Index: dlls/quartz/avisplit.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avisplit.c,v >retrieving revision 1.10 >diff -u -r1.10 avisplit.c >--- dlls/quartz/avisplit.c 27 Dec 2004 17:15:58 -0000 1.10 >+++ dlls/quartz/avisplit.c 29 Dec 2004 09:06:26 -0000 >@@ -327,6 +327,7 @@ > { > HRESULT hr = S_OK; > AVISplitter *This = (AVISplitter *)iface; >+ int i; > > TRACE("(%s)\n", wine_dbgstr_longlong(tStart)); > >@@ -337,6 +338,17 @@ > } > LeaveCriticalSection(&This->csFilter); > >+ hr = PullPin_InitProcessing(This->pInputPin); >+ >+ if (SUCCEEDED(hr)) >+ { >+ for (i = 1; i < This->cStreams + 1; i++) >+ { >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[i]); >+ } >+ hr = PullPin_StartProcessing(This->pInputPin); >+ } >+ > return hr; > } > > And so does this. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >+ if (This->state == State_Running) >+ return S_OK; >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ > return S_FALSE; > } > > And this all needs to be protected by a critical section too. > >@@ -1191,7 +1287,9 @@ > OAFilterState *pfs) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); > >- TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, pfs); >+ TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, msTimeout, pfs); >+ >+ *pfs = This->state; > > > This probably needs protection too. Rob

Dec. 29, 2004

Re: UNICOWS: stub implementations

by Stefan Leichter

Am Dienstag, 28. Dezember 2004 16:22 schrieb Hans Leidekker: > On Tuesday 28 December 2004 15:30, Stefan Leichter wrote: > > you missed to send the implementations of the stubs! > > Well, yes and no. Our unicows doesn't have any implementations itself, it > just links to the dlls that do have them by creating dummy references. For > those dlls I sent patches earlier, so indirectly I did implement the stubs > in unicows, see? > > -Hans Well ok, another brown paper bag for my collection. Stefan

Dec. 29, 2004

Re: lotus notes regression

by Paul R Streitman

Mike, Sorry about that, I edited away the notes level at some point! This is with notes 6.5.3. I can easily reproduce it if you would like me to try anything. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com Mike Hearn <mh(a)codeweavers.c om> To Sent by: wine-devel(a)winehq.com wine-devel-admin@ cc winehq.org Subject Re: lotus notes regression 12/28/2004 08:25 PM On Tue, 28 Dec 2004 19:21:27 -0500, Paul R Streitman wrote: > Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom > is a hang with the CPU at 100%, and it happens immediately if you try to > click on a notes 'bookmark', or shortly after you try to do much of > anything else if you try to avoid the 'bookmarks'. This is the following patch: Log message: Moved update region handling to the server. Patch: http://cvs.winehq.org/patch.py?id=14725 ie, it's a WM rewrite regression. I will investigate when I get a chance. Paul, is this Notes 6.5.1 or an earlier version? thanks -mike

Dec. 29, 2004

Re: ptrace single-stepping change breaks Wine

by Thomas Sailer

Any news about the ptrace single-stepping breakage of wine? The application that stopped working for me is xst, the Xilinx HDL synthesizer (there's a free as in beer version at http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGl… ). I'm currently at kernel 2.6.10-ac1 (as packaged by Arjan van de Ven), and wine-20041201-1fc3winehq. Compiling vhdl file H:/sailer/src/vhdl/xxx/vprim.vhd in Library synwork. 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 Thanks, Tom

Dec. 29, 2004

Re: another build problem on current cvs

by Vincent Béron

Le mar 28/12/2004 à 09:24, Joris Huizer a écrit : > Hello, > > For the past week or so, building from cvs on a debian/stable system w/ > alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks > on alsa-specific code in wine; > I attached the log; note that I did a `cvs update -dPA` and `make > distclean` so this can't be any problem with the source I have > > Any ideas? Maybe you can point me to a place where I can read how to fix > this properly (I never worked on alsa-specific code before...) or > something like that Which version of ALSA do you have headers for? Vincent

Dec. 29, 2004

Re: lotus notes regression

by Mike Hearn

On Tue, 28 Dec 2004 19:21:27 -0500, Paul R Streitman wrote: > Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom > is a hang with the CPU at 100%, and it happens immediately if you try to > click on a notes 'bookmark', or shortly after you try to do much of > anything else if you try to avoid the 'bookmarks'. This is the following patch: Log message: Moved update region handling to the server. Patch: http://cvs.winehq.org/patch.py?id=14725 ie, it's a WM rewrite regression. I will investigate when I get a chance. Paul, is this Notes 6.5.1 or an earlier version? thanks -mike

Dec. 29, 2004

lotus notes regression

by Paul R Streitman

Patch 14725, applied 2004/12/07 11:31:53, breaks lotus notes. The symptom is a hang with the CPU at 100%, and it happens immediately if you try to click on a notes 'bookmark', or shortly after you try to do much of anything else if you try to avoid the 'bookmarks'. Sorry that it took me so long to report this, when I decided that it wasn't just a temporary instability I eventually had to iteratively compile (many) CVS snapshots to narrow down when the problem was introduced because I found it impossible to untangle the various patches that went in around that time frame. I also ran afoul of the jack problems near the end. I do not know how to narrow the problem down further. I tried running winedbg (at CVS level a couple of days ago), and that seems to be broken too -- it wanted to run things from the wine build tree? There are no unusual console messages or anything when the problem happens. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com

Dec. 29, 2004

Re: Windows Admionistrator Rights

by Mark Knecht

I see that the file .wine/user.reg has a line in it that reads "USERPROFILE"="c:\\Windows\\Profiles\\Administrator" but my Windows directory has no Profiles subdirectory in it: mark(a)gandalf Windows $ ls -al total 40 drwxr-xr-x 9 mark users 4096 Dec 28 10:46 . drwxr-xr-x 4 mark users 4096 Dec 28 10:46 .. -rw-r--r-- 1 mark users 0 Dec 28 10:46 .keep drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Desktop drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Favorites drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Fonts drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Inf drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Recent drwxr-xr-x 3 mark users 4096 Dec 28 10:46 Start Menu drwxr-xr-x 2 mark users 4096 Dec 28 10:46 System -rw-r--r-- 1 mark users 481 Dec 28 10:54 win.ini mark(a)gandalf Windows $ Possibly this is part of the problem??? Thanks, Mark On Tue, 28 Dec 2004 14:46:58 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > I'm guessing this means WIne is compiled on this machine in a way that > > doesn't output debug information? > > > > If so (please let me know) then I'll have to look up how to compile > > to include this output. > > I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty > chatty, so the default configure options in the RPM spec file must be what > you need. > >

Dec. 28, 2004

Re: Windows Admionistrator Rights

by Mark Knecht

On Tue, 28 Dec 2004 14:46:58 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > I'm guessing this means WIne is compiled on this machine in a way that > > doesn't output debug information? > > > > If so (please let me know) then I'll have to look up how to compile > > to include this output. > > I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty > chatty, so the default configure options in the RPM spec file must be what > you need. > I'm on Gentoo. It sticks in my mind that there is a configure option that turns this on. It's not on by default. I'm doing this on a relative's Gentoo box right now. On my Gentoo system at home I have debugging turned on so I'll wait until I get there in a couple of days and try again with debugging turned on. My though, having poked around a bit, is that there is a registry entry for each user that says whether the user has admin rights. I think that's not turned on, but I don't know if I turn it on whether it will actually work. This is all guessing. Again, Wine is not bombing out at all. I'm just getting a Windows dialog telling me that I need to be an administrator. - Mark

Dec. 28, 2004

Re: build problem on current cvs

by Jacek Caban

Stefan Leichter wrote: >Am Dienstag, 28. Dezember 2004 11:15 schrieb Jacek Caban: > > >>Hi. >> >>Stefan Leichter wrote: >> >> >>>Hello, >>> >>>i hope you all had nice Christmas. >>> >>>Now back to business :-) >>> >>>trying to build current cvs (~7:45 AM UTC) i get the error: >>> >>>make[1]: Entering directory `/usr/src/wine/wine-build/include' >>>../tools/widl/widl -I../../wine/include -I. -I../../wine/include >>>-I../include -h -H oaidl.h ../../wine/include/oaidl.idl >>> >>> >>>../../wine/include/wtypes.idl:1: Oops, segment violation >>>make[1]: *** [oaidl.h] Abgebrochen >>>make[1]: *** Datei »oaidl.h« wird gelöscht >>>make[1]: Leaving directory `/usr/src/wine/wine-build/include' >>>make: *** [include] Fehler 2 >>> >>>My system is still SuSE 9.0. I am doing 'out of tree' builds. >>> >>>Bye Stefan >>> >>> >>Did you do make depend? >> >>Thanks, >> Jacek >> >> > >this happens for me during make depend ;-) > >Thanks Stefan > > > Could you try debug widl by gdb? Try: $ gdb --args ../tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include -h -H oaidl.h ../../wine/include/oaidl.idl

Dec. 28, 2004

Re: Windows Admionistrator Rights

by Kenneth Porter

--On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht <markknecht(a)gmail.com> wrote: > I'm guessing this means WIne is compiled on this machine in a way that > doesn't output debug information? > > If so (please let me know) then I'll have to look up how to compile > to include this output. I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty chatty, so the default configure options in the RPM spec file must be what you need.

Dec. 28, 2004

Re: Windows Admionistrator Rights

by Mark Knecht

Kenneth, There are no messages when I run Wine like this: WINEDEBUG=+all wine setup.exe I'm guessing this means WIne is compiled on this machine in a way that doesn't output debug information? If so (please let me know) then I'll have to look up how to compile to include this output. - Mark On Tue, 28 Dec 2004 14:21:32 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 11:12 AM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > How can I tell Wine to trick an install program into thinking the user > > has administrator rights under Windows XP? I've switched the windows > > type in the config file to winxp but the install program for Autocad > > 2005 tells me to log in again as an administrator. > > My guess is that it's either unable to write to a system directory or it's > looking for a certain group membership. Try tracing the installer and see > if it's doing something like that. > >

Dec. 28, 2004

Re: Windows Admionistrator Rights

by Kenneth Porter

--On Tuesday, December 28, 2004 11:12 AM -0800 Mark Knecht <markknecht(a)gmail.com> wrote: > How can I tell Wine to trick an install program into thinking the user > has administrator rights under Windows XP? I've switched the windows > type in the config file to winxp but the install program for Autocad > 2005 tells me to log in again as an administrator. My guess is that it's either unable to write to a system directory or it's looking for a certain group membership. Try tracing the installer and see if it's doing something like that.

Dec. 28, 2004

ptrace + Warcraft 3 issues remain (2.6.10)

by Jesse Allen

Last I reported on Warcraft 3 with the ptrace changes in 2.6.10-rc3 is that it made some improvement, but still doesn't work. I'll will describe in detail what I know now. Since the changes in 2.6.10-rc3, Linus made a very good clean up of ptrace.c and signal.c in arch/i386/kernel. I don't want to necessarily reverse all these changes because they are good changes (ie easier to understand and hack now). So I hacked the kernel to change what is necessary to make the game run again. I have attached the patch against 2.6.10 to show the required changes. Comments on what I have learned about the 3 ptrace changes (see my original report): #1 ptrace.c In set_singlestep() and clear_singlestep(), the flag TIF_SINGLESTEP is now set and cleared. In the header file in include/asm-i386/thread_info.h, it seems to indicate to me that it is an internal flag to remember to re enable single-stepping for a thread on returning to the program. While speaking to my brother on this, we believe that this change was done correctly. But this change alone will break the game. I have looked in both wine for PTRACE_SINGLESTEP to see what it does and in the kernel for TIF_SINGLESTEP. Since set/clear TIF_SINGLESTEP causes the problem, I really need more information on everything about TIF_SINGLESTEP. #2 signal.c - Not single-stepping into signal handlers unless the tracer requests it Previous to 2.6.9-rc2, my understanding is that a call to setup_frame() would clear the trap flag in preparation for a signal delivery. Roland made a slight tweak to it and an example of it is this: if (regs->eflags & TF_MASK) { if (current->ptrace & PT_PTRACED) { ptrace_notify(SIGTRAP); } else { regs->eflags &= ~TF_MASK; } } Linus later changed it to: /* * Clear TF when entering the signal handler, but * notify any tracer that was single-stepping it. * The tracer may want to single-step inside the * handler too. */ if (regs->eflags & TF_MASK) { regs->eflags &= ~TF_MASK; if (current->ptrace & PT_DTRACE) ptrace_notify(SIGTRAP); } In 2.6.10, this new piece of code actually works with Warcraft III. I no longer have to reverse this change. The result is obvious because it makes it so you don't automatically single step into the handler, which wine doesn't really want. #3 signal.c - Clearing the trap flag if being traced by debugger in setup_sigcontext() For some reason, Warcraft III doesn't work if it is cleared here. I have no idea if this TF clear is really necessary. However, everything I've read on this seems to indicate to me that this change is important, so I need to find out what this causes to the game. I captured a log of the seh debug messages because I think this is may be where to look. I also hacked in to display trace messages in wine's dlls/ntdll/signal_i386.c showing eflags and whether TF is cleared in trap_handler() and raise_trap_exception(). I ran the game under 2.6.10 and the modded 2.6.10, to capture the working version, and the failing version. The results are fairly nonrandom and comparable and you can identify differences. Unfortunately, I cannot upload them at the moment because my connection is slow and the files are large. I'll upload it another time. Jesse

Dec. 28, 2004