2009-08-26
What packages SystemTap requires on Ubuntu 8.04 (and others)
For my own future reference and because the SystemTap wiki is not the clearest thing on this, here's what packages are required to be able to use SystemTap on various distributions.
We use the -server kernels on our Ubuntu 8.04 machines, so I needed to do:
apt-get install systemtap linux-image-debug-server linux-headers-server
ln -s /boot/vmlinux-debug-$(uname -r) /lib/modules/$(uname -r)/vmlinux
In the Ubuntu/Debian way, the linux- packages are generic ones that will pull in the necessary kernel version specific package. I believe that this adds about 60 MBytes of disk space usage.
(Mostly researched from here, which believes that you also need additional bits that I didn't.)
The Red Hat Enterprise 5 directions from the SystemTap wiki are accurate. Note that the necessary packages added up to over 600 MBytes (of installed space) on my x86_64 test system.
Although I haven't tested them, I believe that the Fedora directions are basically
accurate. Current versions of Fedora don't need you to explicitly
install the kernel-devel RPM, as the systemtap RPM already depends
on it. (It does not on RHEL for some reason.)
I find it both unfortunate and a sign of a somewhat broken package system that both Ubuntu and Fedora/RHEL need extra steps to make SystemTap work; in a sensible world, simply installing SystemTap would install all of its dependencies. I understand why both Ubuntu and Fedora/RHEL are broken, I just don't think that they should be.
(Ubuntu is broken mostly because it has no fixed package name that means 'the current kernel, whatever that is', which I think is ultimately because the Debian package format lacks multi-arch support, although I haven't looked deeply into this. Fedora and RHEL are broken because they put the necessary kernel debugging packages into non-default repositories, possibly so that users aren't confused by a profusion of -debuginfo RPMs in various listings of available packages. Since the kernel debuginfo RPMs are huge, it would be nice to have smaller ones in the main repository that just had the data that SystemTap needs.)
A frame object's f_locals isn't always the locals
Python frame objects have a tempting member called f_locals, which
is described as the 'local namespace seen by this frame' (to quote the
inspect module). This is
slightly misleading, because it is not always what Python programmers
normally think of as 'locals'.
Specifically, if the frame comes from code that is running at the
module level, f_locals is the 'local namespace' of that code,
that is, it is the module's namespace. In other words, it's the same
as f_globals, and in fact both of them are live references to the
module's name dictionary.
This is a gotcha because it means that f_locals has significantly
different behavior between module level code and function level code.
For module level code, you can modify f_locals and it actually
works; for function level code, modifying f_locals doesn't do
anything.
(Perhaps it would be better if f_locals was always read only.
There's plausible ways of making this inexpensive for module level
frames.)
You might now wonder how you tell if a frame belongs to module level
code or function level code. One answer is that you can look at
f_code.co_name, which will be "<module>" for module level code.
You can also see if f_locals and f_globals are the same thing.
(I suspect that you can play extensive games with eval() that will
fool some or all of these checks. So don't do that.)
On a side note, the other odd looking frame object member is
f_builtins. Under most circumstances, this is the same as
__builtins__.__dict__.
(My attention was drawn to this confusing situation by Multi-Line Lambdas in Python Using the With Statement by Bill Mill.)