pcp
[Top] [All Lists]

Re: pcp updates - grab bag of post-3.8.0 goodies

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pcp updates - grab bag of post-3.8.0 goodies
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 21 May 2013 10:26:57 -0400
Cc: Nathan Scott <nathans@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <519ABE8A.10906@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Tue, 21 May 2013 10:23:38 +1000")
References: <519AAB0E.30107@xxxxxxxxxxxxxxxx> <698804565.6877022.1369093462884.JavaMail.root@xxxxxxxxxx> <519ABE8A.10906@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Ken McDonell <kenj@xxxxxxxxxxxxxxxx> writes:

> [...]
>> Perhaps we can tackle fault injection in a less invasive manner (using
>> the regular library builds) with systemtap and/or dyninst someday.
>
> I can see the merit in this approach for the engineer validating a
> hypothesis or code change.  I would be interested to hear if anyone
> has experience (leading question!) using this approach for systemic QA
> and regression testing of released code.
>
> For libpcp_fault, almost none (2 of 17) of the fault injection points
> are at the entry point to a routine, so we'd be relying on source line
> numbers to align the fault point with the logic of the source code
> ... this seems rather fragile to me.

(These injection points could be identified by name rather than source
coordinates.)

glibc folks have started investigating fault injection instrumentation
for much the same reasons as here.  [1] is the current tail of the
discussion.  There's an opportunity to prototype something in one
project and have it be adopted in the other.

[1] http://sourceware.org/ml/libc-alpha/2013-05/msg00191.html

- FChE

<Prev in Thread] Current Thread [Next in Thread>