On Wed, 25 Nov 2009 22:17:15 +0100, Roland McGrath wrote:
> > In general everything where is a word "thread" has unstable results and
> > "nonstop" tests are also a bit unstable.
>
> So where exactly is the problem in these cases? Are the tests overly
> timing-sensitive where there is no actual behavior bug? Or is gdb overly
> timing-sensitive where there is no actual kernel bug? Or is it just
> unknown, and might be a kernel bug after all (even an undiagnosed one in
> vanilla kernels)?
gdb.server/server-run.exp: gdbserver contains data overflow/corruption,
occasionally it crashes, occasionally passes.
gdb.mi/mi-nonstop-exit.exp: Some race in GDB non-stop code.
gdb.threads/attach-stopped.exp: Race in the testcase (I think so).
etc.
But in most cases I do not know, gdb.log is commonly not enough to find the
problem and when it is not reproducible on the 2nd..nth run... But I+upstream
already caught many races but still a lot of them remains.
> > There are IMO/hopefully very few cases tested by the gdb testsuite and still
> > not covered by the ptrace-testsuite, I even do not much expect we will see
> > again a new utrace regression caught by the gdb testsuite && uncaught by the
> > ptrace-testsuite.
>
> That's certainly good to hear. If you are pretty confident about that,
> then I am quite happy to consider nonregression on all of ptrace-tests the
> sole gating test for kernel changes. We just don't want to wind up having
> other upstream reviewers notice a regression using gdb that we didn't
> notice before we submitted a kernel change.
I did not verify the GDB codebase for all the ptrace calls in any way.
If it is a kernel patch submit after long development period it is probably
still worth checking it against GDB.
> > Please point at some built or easily buildable kernel .rpm first.
>
> http://kojipkgs.fedoraproject.org/scratch/roland/task_1825649/
OK, taken for reverification.
Regards,
Jan
