And Swfdec’s day, too. First I merged the new debugger into master without any issues. So now everyone hacking on Swfdec can profit from Vivified greatness.
After doing so, I used it. And made bloxorz.swf go from this:
to this:
And if that wasn’t enough, I made Kittencannon work. Here’s the 23MB proof in slow motion. And to top it all off, Pekka has finished making variable flags work. 4 awesome things in one day.
Both of those bugs were longstanding bugs where I had no idea what was causing them. It’s one of the things I have been thinking about a lot. Swfdec is a virtual machine that runs for a long time and at some point you notice something is wrong. But how do you figure out which of the thousands or millions of executed statements caused it? So far the only solution I had was using my knowledge of the codebase and printf debugging, which is not really that great. gdb is not really helpful for stuff that runs for long times, as it always interrupts and it’s hard to inspect the running program.
Vivified so far is only two things: 1) an improved way to insert printfs – by inserting prints in the debugger’s hooks and 2) a UI for common things to look at, so printf isn’t needed. Vivified keeps a tree of the currently running movieclip instances, so it’s easy to see when one goes away when it shouldn’t, even an invisible one. It helps tremendously (see above), but I have the feeling it can be done way better.
When looking at other software with the same problems in Gnome land, there isn’t really a lot. Most Gtk applications aren’t long-running, they’re mostly short snippets of code after a user action. The parts that are (session startup) pretty much use the same approach that GStreamer uses, and that approach is the old one: printf. GStreamer just has this glorified printf framework where one has to look through 3GB of output to find a bug, which is neither easy nor intuitive. So I guess I should end this rambling with a “dear interweb”: Dear Interweb, do you know of ways to debug long running applications and find bugs that happened 20 minutes ago but only caused a problem now?
7 comments ↓
Yes, it’s called DTrace :)
Checkout this presentation.
How about Chronomancer. It’s rather new and I haven’t tried it personally but it might be useful:
http://weblogs.mozillazine.org/roc/archives/2007/08/announcing_chro.html
Open-source-wise, there’s the recently released chronicle-recorder (http://code.google.com/p/chronicle-recorder/) which uses valgrind as a basis to produce an execution trace which you can then issue JSON queries against to find out things, or probably preferably, use the even more recently release GUI, chronomancer (http://code.google.com/p/chronomancer). The bad news is that the traces may be ridiculously large if you’re talking 20 minutes ago that the bug happened, let alone if the program has been running even longer than 20 minutes. Also, a bit of slowdown.
Not open source, there’s the new VMware technology that logs the non-determinism in your virtual machine’s execution so that your session can be replayed in a debugger; I believe they support attaching gdb to your program inside the virtual machine. You’ll have to google for that, but I’ve seen threads about it on planet gnome…
Robert O’Callahan’s “Chronomancer” (http://code.google.com/p/chronomancer/) is supposed to do pretty much exactly that.
Seeing as you’re getting the important sites working, I hope Nanaca Crash works too ;) http://www.geocities.jp/lledoece/nanaca-crash.html
Can you set up a test harness to run your VM and the Macromedia one in tandem and compare results after each instruction? Sure it’s slow but just let it run for a couple of days. You can probably build a fast forward feature into it to run 10M instructions before starting to compare.
Chronomancer, an eclipse plugin which is based on Chronicle which hooks into Valgrind and records every memory and register write.