|
From: Tom H. <to...@co...> - 2005-02-11 14:55:23
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> Stack traces are tricky. We shouldn't just ignore them, because
> they're an important part of the test -- we want them to fail if they
> eg. don't get the line number right. Basically, we want a certain
> level of fuzziness in the stack trace comparison, probably more than
> we have now. I would suggest reworking the filter_stderr_basic script
> to strip out more of the unimportant info from traces. But first, we
> should look at representative examples of test failures caused by
> insufficient fuzziness, so we can see exactly what we should strip
> out. Can Tom or Jeremy provide these?
This is a typical failure:
! at 0x........: accept (in /...libc...)
--- 5 ----
! at 0x........: accept (socket.S:63)
The current stripping strips "/.*libc.*" to "...libc..." which is
fine if there is no debug information available.
If debug information is available then you just get the name of
the source file and the line number, and there is no sane way to
know that socket.S is part of glibc and strip it to "...libc..." so
that it matches.
I guess that one option for many tests would be to discard the
location completely and just keep the function name?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|