-
Mortadelo now monitors almost all the syscalls that "strace -e trace=file" would give you, that is, the syscalls to which you pass a filename.
This is where things start to get really interesting, as you can see apps doing silly things pretty quickly.
-
Yesterday I added search-as-you-type to Mortadelo. You simply type a regular expression and the display updates itself as you type.
Do you only want to show syscalls for a particular process? Just type the process name. Want to filter on a specific PID? Just type the PID. Want to search in the arguments? Just type what you are looking for.
Timestamps are also human-readable now; we used to display just microseconds after the epoch.
-
Mortadelo: a graphical, systemwide strace
As part of openSUSE Hack Week, I am pleased to bring you Mortadelo, a graphical, systemwide version of strace.
Here you can see Mortadelo showing open(2) calls for all the processes running in the system, in the order in which they happen. Failed open() calls are highlighted in red. You can browse the log in real-time, or you can save it and load it later for analysis.
Mortadelo started life as a simple clone of Filemon, a Windows utility that is essentially a systemwide strace(1) with a friendly user interface. System administrators use Filemon in Windows to solve the same kinds of problems that a Linux admin would use strace for — see which nonexistent file a program tried to open before it crashed, see permission errors in files, etc.
People who are not familiar with the cultural heritage of Spain may be wondering about Mortadelo's name. Go and find out.
Mortadelo requires the incredible Systemtap to be installed.
You can get an extremely early development version of Mortadelo with this:
git-clone http://www.gnome.org/~federico/git/mortadelo
-
I've been writing a little GUI tool on top of Systemtap, using Mono. After using Python for a while to hack on Sabayon and for little profiling/plotting tools, I have some thoughts about both development platforms.
Mono pros:
You can use structs to aggregate values without consing (in Python you'd have to use a class). I need pretty large arrays of structs; exploding them to classes would use too much memory.
NUnit makes it really nice to write unit tests. Finally, a painless way to implement "make check".
The profiling tools are reasonably nice. Heap-buddy is very nice.
Really easy to call C functions when the bindings don't have something you need. You can even pass callbacks without bullshit.
Lambdas.
Monodoc.
"enum Foo { Bar, Baz, Beep }" is just much nicer than "(Bar, Baz, Beep) = range (oh-how-many-elements-again?)"
Mono cons:
No debugger in SLED 10.
The edit/compile/run cycle is the same as always, though it is so much faster than C. You can't test things quickly without an interpreter, but the ultra-fast compiles almost make up for it.
Gtk-sharp is just not as smooth and comprehensive as Pygtk.
Namespace diarrhea makes low-level Unix things hard to find. Mono.Unix.UnixStream to read from a file descriptor feels too hidden (though it handles EINTR automatically, hurrah!). Mono.Unix.Native.Syscall.setsid() instead of simply os.setsid(). Fortunately, you can do this to make things less verbose:
using unix = Mono.Unix.Native.Syscall; ... int pg = unix.setsid ();
Creating streams and plugging them to stream readers/writers seems like too much typing, though it's certainly nice to have file / memory / string streams which you can plug together.
Doing "push" pipelines (friendly to GSource IO callbacks) is hard with streams. I don't want to mess up my code with "pull" pipelines inside threads just yet.
To have an array with possibly empty subarrays, I have to write
int [][] expected_modified = { new int[0] { }, new int[1] { 0 }, new int[0] { }, new int[0] { }, new int[0] { }, new int[1] { 3 }, new int[0] { } };instead of
expected_modified = [ [], [0], [], [], [], [3], [] ]
Admittedly, I could have
int[,] expected_modified = new int[7, 2] = { { -1, 0 }, { 0, -1 }, { -1, 0 }, { -1, 0 }, { -1, 0 }, { 3, -1 }, {-1, 0 };with -1 for terminators, but it's not as pretty.
I cannot inline-initialize an array of structs without defining constructors and typing a lot of "new MyStruct". Miguel says this is fixed with LINQ in newer revisions of the language.
I fix all errors that the compiler reports, and the next compilation throws more errors.
Python pros:
The interpreter makes it really easy to test things by trial and error quickly, or to remind yourself of the syntax of the language. *Especially* regexps.
Late binding.
Dynamic typing.
No need to make things "public" explicitly.
Working, useful debugger.
Low-level Unix functions seem easy to find in the class library.
Pygtk is just fantastically well-done.
Python cons:
Really hard to call C functions. This is a killer.
No lexical scoping.
Useless lambdas.
Slow.
Hard (impossible?) to make cons-free structures. For this particular program, this is a killer.
Overall:
I'm not writing new programs in C ever again.