Omniscient Debugging is an idea that looks very very sexy. In short: it's a complete trace of a program after it ran - all variable assignments, function calls, exception throws/catches, etc. Once your program finished, you can retrace its whole execution history, step by step.

Imagine that your program failed. So, you have to run it again, fill in lots of "print" statements, perhaps even firing up the debugger and starting throwing breakpoints in. With ODB, it's not necessary. Even for multithreaded programs, it provides a completely deterministic run history that can be used (and in fact, was displayed in action) to find bugs very quickly. People who use it swear by it, hotly claiming that it shaves off huge amounts of debugging time.

Now, that catch is - this ODB thingie was developed for Java, since its virtual machine allows a simple & relatively efficient implementation of an ODB to sit on it. It probably isn't too applicable to compiled code.

But I guess Perl can have support for this as well ? Perl 6, especially, which also runs on top of a VM... Can Parrot support this ? The Perl 6 compiler, perhaps (inserting "timestamping" instructions before/after assignment/call instructions)

Replies are listed 'Best First'.
Re: "omniscient debugging" for Perl
by praveenray (Novice) on Jul 05, 2005 at 16:12 UTC
    If I remember it right, according to Autrijus's presentation at YAPC::Toronto, we'll be able to do exactly this in Perl 6. He was even talking about being able to maintain entire state of the application in few KiloBytes..thereby eliminating the need for cookies !! Really cool. Whenever we're blessed with it.
[reply]
      How does this eliminate the need for cookies (I'm assuming you mean web browser cookies)? No matter how much you can save on the server side, HTTP is stateless and you need some piece of data coming from the client to indicate that this request is tied to a previous request (or series of requests). Even if you could save the application state of every Apache child (assuming Apache) for every simultaneous user, there is still no way to figure out which one to use for the next request.

      -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier
[reply]
        How does this eliminate the need for cookies? ... No matter how much you can save on the server side, HTTP is stateless and you need some piece of data coming from the client to indicate that this request is tied to a previous request ...
        If you can represent the entire state compactly enough, you can send it back to the client with every response and receive it from the client with every request. Now you don't need to store any state on the server, nor do you need cookies on the clients.

        For example, take a look at Web Authoring System Haskell. It records a journal of client-server interactions, sends this journal to the client as part of every response (in a hidden field in an HTML form), and when the form is submitted, it replays the journal on the server to recreate the state.

        Cheers,
        Tom

        Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]
Re: "omniscient debugging" for Perl
by Jenda (Abbot) on Jul 05, 2005 at 17:20 UTC

    There's one problem with seeing everything. The fact that you see everything. In the loads of data it's awfully hard to find the bits you need. Unless the post-mortem debugger allows for very good filering I think all this information gets in the way more than it helps.

    Actually I think if this thing is so helpfull to you, there's probably something wrong with your programming style. The program is not modularized enough, the modules are not unit tested, ...

    Jenda
    XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

[reply]
Re: "omniscient debugging" for Perl
by magog (Beadle) on Jul 05, 2005 at 19:18 UTC

    A perl tool that sorta kinda works this way is Devel::Trace 

        perl -d:Trace program.pl

    [download]

    Mind you, it only prints out the flow of execution; it doesn't actually let you inspect variables or anything like that. It's still pretty useful, though. I just wish I could find a way to switch it on and off at runtime under mod_perl. :)

    Michael

[reply]
[d/l]
      A quick glance at the source shows that MJD is using the global $TRACE to decide if the trace output should be printed. Just set $TRACE = 0 at the top of your program, set it to a non-zero value when trace should start, and back to zero again when you want it off again.

      Simple.

[reply]
[d/l]
[select]

        Thanks for the tip, pemungkah!

        The other problem is how to get the -d:Trace option to work under mod_perl.

        Here's how to do it:

        Add the following section to httpd.conf: 

           <Perl>
       $Devel::Trace::TRACE = 0;
   </Perl>

        [download]

        And start the server like this: 

            $ PERL5OPT=-d:Trace sudo /etc/init.d/httpd restart

        [download]

        Then in your code you can write: 

           $Devel::Trace::TRACE = 1;
   # some buggy code
   $Devel::Trace::TRACE = 0;

        [download]

        Problems:

        • Server spits out a mess of trace info before $TRACE is set to 0
        • Trace info (and there's a lot of it) goes to the error log, which is hard to manage

        I think I'll try making a patch to allow turning off $TRACE via the command line, and to allow sending the trace info to a different file.

        Michael

[reply]
[d/l]
[select]
Re: "omniscient debugging" for Perl
by dave_the_m (Monsignor) on Jul 05, 2005 at 20:20 UTC
    A perl build with -DDEBUGGING can show much information during execution, for example each op being executed, and the contents of the stack after each op: 
    $ perl587 -Dst -e'$a = "abc"; $a .= 1'

EXECUTING...

    =>
(-e:0)  enter
    =>
(-e:0)  nextstate
    =>
(-e:1)  const(PV("abc"\0))
    =>  PV("abc"\0)
(-e:1)  gvsv(main::a)
    =>  PV("abc"\0)  UNDEF
(-e:1)  sassign
    =>  PV("abc"\0)
(-e:1)  nextstate
    =>
(-e:1)  gvsv(main::a)
    =>  PV("abc"\0)
(-e:1)  const(IV(1))
    =>  PV("abc"\0)  IV(1)
(-e:1)  concat
    =>  PV("abc1"\0)
(-e:1)  leave

    [download]

    Dave.

[reply]
[d/l]
Re: "omniscient debugging" for Perl
by spiritway (Vicar) on Jul 10, 2005 at 11:25 UTC
    I don't doubt that this idea can be implemented for Perl. The question is whether the benefits warrant it. Always we must ask, "How much does it cost?" Will the program still run within a reasonable amount of time, and will the output be manageable? Often our problem is not too little information, but too much.
    I believe that most of debugging involves tracking down flaws in logic, and that applying a sort of "shotgun" approach to it is not ideal. A few well-chosen "reality checks", print statements to check values of variables, can isolate a problem in most cases.
[reply]

Back to Meditations