public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "Stone, Joshua I" <joshua.i.stone@intel.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <systemtap@sources.redhat.com>
Subject: RE: Stress testing - all functions
Date: Mon, 03 Apr 2006 19:21:00 -0000	[thread overview]
Message-ID: <CBDB88BFD06F7F408399DBCF8776B3DC06D3CD7F@scsmsx403.amr.corp.intel.com> (raw)

Frank Ch. Eigler wrote:
>> d*: system reboots - there was no OOPS or BUG or anything printed to
>> the console.
> 
> Given time, one can try d[a-m]* and d[n-z]* to recursively subdivide
> the namespace.  It would be great if this were done automatically.  (A
> full search would of course take lots of time due to reboots.)

Don't forget [A-Z0-9_] in legal identifiers as well.  I had forgotten
the capitals at first, so I will update the test accordingly.

What you suggest is somewhat painful to implement since stap uses glob
matching, not regex.  However, given that testing success is cheap and
failure is expensive (reboot), a linear sweep of da*, db*, etc.
suffices.  In this way you isolate one more letter for each reboot you
endure.

I narrowed this crash down to 'do_*', and then I was fortunate to get a
stack trace on 'do_d*'.  The trace shows a cycle of
do_debug->do_page_fault->error_code->do_debug->(loop).  I've been unable
to reproduce this with probing either do_debug or 'do_d*'.  Probing
'do_*' always reboots immediately though, completely reproducible.

>> The two that failed in a* and c* are both functions that are
>> decorated with __exit.  Perhaps the translator needs to disallow
>> __exit functions, just as it disallows __init?
> 
> That's right, for routines that are linked into vmlinux (not in a
> module).

In all, fourteen letters of the alphabet fail on inserting probes on
__exit functions, so this is a blocking issue for doing more complete
tests.  I will file a bugzilla on this, and if it's not difficult I'll
go ahead and try to fix it.


Josh


(BTW, these results are all from i386 RHEL4 U3, w/ Anil's backported
patches)

             reply	other threads:[~2006-04-03 19:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-03 19:21 Stone, Joshua I [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-04-01  1:39 Stone, Joshua I
2006-04-01  2:44 ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CBDB88BFD06F7F408399DBCF8776B3DC06D3CD7F@scsmsx403.amr.corp.intel.com \
    --to=joshua.i.stone@intel.com \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).