This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Using systemtap to validate manual code inspection.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 7 May 2013 15:05:27 +0200
- Subject: Re: Using systemtap to validate manual code inspection.
- References: <51875E96 dot 8030901 at redhat dot com> <20130507091426 dot GB5741 at spoyarek dot pnq dot redhat dot com> <5188F30E dot 8030203 at redhat dot com>
On Tue, May 07, 2013 at 08:26:54AM -0400, Carlos O'Donell wrote:
> On 05/07/2013 05:14 AM, Siddhesh Poyarekar wrote:
> > On Mon, May 06, 2013 at 03:41:10AM -0400, Carlos O'Donell wrote:
> >> I recently had to do some manual code inspection
> >> for a bug which has no reproducer (patch forthcoming).
> >>
> >> The manual inspection found real bugs, but I wanted
> >> to get more coverage for the failure scenarios.
> >>
> >> I wrote up my experience using systemtap to inject
> >> failures into glibc:
> >> http://sourceware.org/glibc/wiki/Testing/WhiteBox
> >>
> >> Looking forward to white box and unit tests ;-)
> >
> > This is really neat, but the problem here is not limited to systemtap
> > needing root privileges. The more subtle problem is the dependency of
> > these tests on line numbers within code. The tests will have to be
> > continually updated as the code gets updated and that may blow out of
> > proportion as the number of such tests per source file grows.
> >
> > It would be nicer if it were possible to add annotations within source
> > that systemtap picks up and set probes at those points. I'm not
> > talking about probe points, since they're additional code within the
> > library and not just source level annotations. Something like this:
> >
> > some_func (int *in)
> > {
> > /** SYSPROBE:probe=simulate_crash;file=simulate_crash.stp */
> > glob = *in;
> > }
> >
> > The problem with doing this is that it could quickly clutter up code
> > with white box testing annotations.
>
> The implementation details of adding white box testing
> to glibc is certainly a complex and difficult topic that
> will require some designing :-)
>
> Line numbers are certainly a pain to update.
>
> We really want an automated way to generate the .stp
> file from an annotation and have that become a whitebox
> test associated with a particular test.
>
> e.g.
>
> * Annotate source.
> * Auto-generate .stp files from source.
> * Run test-stpN with .stp file active.
> * Observe PASS/FAIL.
>
You can do this without annotating source. Use diff approach, for probe
copy fragment consisting of three lines before and three after with
relevant code, for example bug with freed memory could be writen as:
START_DIFF
some_func (int *in)
{
+ PROBE{
+ free(in);
+ }
glob = *in;
}
END_DIFF
Three lines are in 99.9% cases enough to uniquely determine position in code, when ambiguous
write bigger fragment.
Ondra