This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: script(s) for tracking execution paths
William Cohen writes:
> Tom Zanussi wrote:
> > William Cohen writes:
> > > Tom Zanussi wrote:
> > > > Hi,
> > > >
> > > > I've been having some fun playing around with maps keyed on stack
> > > > traces (very cool to be able to do this) and have checked into
> > > > systemtap.samples a systemtap script (kmalloc-stacks.stp) and a perl
> > > > script (kmalloc-top) that in combination continuously track the
> > > > different execution paths to kmalloc(). It keeps counts of the
> > > > different execution paths in a systemtap hash, and periodically dumps
> > > > the hash contents (and clears the hash table) to the perl script,
> > > > which rehashes them in user space. At the end of the run (Ctrl-C), it
> > > > sorts the accumulated hash table and filters out any stacks that
> > > > contain any of the user-supplied regexps (-e option), which helps cut
> > > > down on noise e.g.
> > > >
> > > > # ./kmalloc-top -e sys_select,alloc_skb
> > > >
> > > > Here's an example of the output (gathered over a kernel compile):
> > >
> > > Hi Tom, I have been playing around with the kmalloc example you checked
> > > in. When running it, I have seen a couple panics like the one in the
> > > photo at:
> > >
> > > http://people.redhat.com/wcohen/100_0405.jpg
> > >
> > > This is on a pentium III machine running the rawhide with the current
> > > kernel:
> > >
> > > Linux trek.devel.redhat.com 2.6.13-1.1555_FC5smp #1 SMP Wed Sep 14
> > > 15:59:49 EDT 2005 i686 i686 i386 GNU/Linux
> > >
> > >
> >
> > Hmm, I haven't seen anything like that on my machine, a Pentium 4
> > running 2.6.12-1.1447_FC4.
> >
> > Is there anything in particular you do to make it happen? The
> > sytemtap script itself is pretty simple and doesn't do anything out of
> > the ordinary as far as I can tell. I see _stp_map_del() in the trace
> > - is that always the case?
> >
> > Tom
>
> I started the kmalloc-top in one login and did a compile of systemtap in
> the other. I was using the stap from the RPM build earlier this week,
> 0.4.1. Looking at the other picture I took I also see _stp_map_del()
> there too.
It looks like what may be happening is that the map is still in use by
the timer.jiffies() handler when it gets deleted by _stp_map_del() in
the module exit code.
Tom