Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28197 > unrolled thread

Yet another debugging technique

Back to article view | Back to comp.lang.java.programmer

Contents

  Yet another debugging technique Roedy Green <see_website@mindprod.com.invalid> - 2014-04-23 06:35 -0700
    Re: Yet another debugging technique Silvio <silvio@internet.com> - 2014-04-23 16:46 +0200
      Re: Yet another debugging technique Roedy Green <see_website@mindprod.com.invalid> - 2014-04-23 08:47 -0700
      Re: Yet another debugging technique Roedy Green <see_website@mindprod.com.invalid> - 2014-04-23 09:36 -0700

#28197 — Yet another debugging technique

If you look at my website, mindprod.com, you will see that a large
part of it is generated by various computer programs.

If I run the output through HTMLValidator, or eyeball it, or view it
in a browser, it is generally pretty easy to find errors. The hard
part is figuring out where that error was generated in the
corresponding code.

I had an idea years ago for a tool to solve that problem, but no one
was interested.  It worked like this:

In debug mode there is a hook in the text-output functions to,
whenever you write a line, makes a log entry including the offset in
the file and where in the program it called the io that wrote it.
The log entry would be in compact binary (something like serialized
ObjectStream), but in essence it would look something like this:
at com.mindprod.prices.Prices.emitDetailsAndManual line:1059

The output is perfectly normal and you can do anything you would
normally do with it.  However, there a magic viewer for the file.
When you right click on any character, it will tell you the program
and line number that wrote it.  It looks the filename and offset up in
the log file, which is massaged to make finding fast.

I needed such a tool tonight, but I had too many things on my plate
and did not have time.  Further I did not know how to insert the hook
without changing the names of the io methods.

So I cooked up something a little more primitive.


    /**
     * tell you where in the code you are, class/method/line
     *
     * @param depth Set to 1 if you call youAreHere directly.
     *              Set to 2 if you call it indirectly via a piece of
code that
     *              does something with the String it generates, and
you
     *              really want the location of its caller.
     */
    public static String youAreHere( int depth )
        {
        final Throwable t = new Throwable();
        final StackTraceElement[] es = t.getStackTrace();
        final StackTraceElement e = es[ depth ];
        return "at "
               + e.getClassName()
               + "."
               + e.getMethodName()
               + " line:"
               + e.getLineNumber();
        }

I then peppered my code with calls to this method.  I inserted the
String it gives back into the output stream inline, as an HTML
comment. 

<!-- at com.mindprod.prices.Prices.emitDetailsAndManual line:1059 -->

By turning a debug switch on and off I could control
whether these comments were inserted.

There is a problem.  You can't just insert <!-- ... --> ANYWHERE in
HTML. So I had to manually back off and suppress the insertion in
spots where the comment could confuse an HTML parser, e.g. inside
comments or inside macros which are officially comments.  If I had a
tool such as above, that would not be a problem. The generated stream
would be intact no matter where I made my log entries.

-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

[toc] | [next] | [standalone]

#28198

On 04/23/2014 03:35 PM, Roedy Green wrote:
> If you look at my website, mindprod.com, you will see that a large
> part of it is generated by various computer programs.
>
> If I run the output through HTMLValidator, or eyeball it, or view it
> in a browser, it is generally pretty easy to find errors. The hard
> part is figuring out where that error was generated in the
> corresponding code.
>
> I had an idea years ago for a tool to solve that problem, but no one
> was interested.  It worked like this:
>
> In debug mode there is a hook in the text-output functions to,
> whenever you write a line, makes a log entry including the offset in
> the file and where in the program it called the io that wrote it.
> The log entry would be in compact binary (something like serialized
> ObjectStream), but in essence it would look something like this:
> at com.mindprod.prices.Prices.emitDetailsAndManual line:1059
>
> The output is perfectly normal and you can do anything you would
> normally do with it.  However, there a magic viewer for the file.
> When you right click on any character, it will tell you the program
> and line number that wrote it.  It looks the filename and offset up in
> the log file, which is massaged to make finding fast.
>
> I needed such a tool tonight, but I had too many things on my plate
> and did not have time.  Further I did not know how to insert the hook
> without changing the names of the io methods.
>
> So I cooked up something a little more primitive.
>
>
>      /**
>       * tell you where in the code you are, class/method/line
>       *
>       * @param depth Set to 1 if you call youAreHere directly.
>       *              Set to 2 if you call it indirectly via a piece of
> code that
>       *              does something with the String it generates, and
> you
>       *              really want the location of its caller.
>       */
>      public static String youAreHere( int depth )
>          {
>          final Throwable t = new Throwable();
>          final StackTraceElement[] es = t.getStackTrace();
>          final StackTraceElement e = es[ depth ];
>          return "at "
>                 + e.getClassName()
>                 + "."
>                 + e.getMethodName()
>                 + " line:"
>                 + e.getLineNumber();
>          }
>
> I then peppered my code with calls to this method.  I inserted the
> String it gives back into the output stream inline, as an HTML
> comment.
>
> <!-- at com.mindprod.prices.Prices.emitDetailsAndManual line:1059 -->
>
> By turning a debug switch on and off I could control
> whether these comments were inserted.
>
> There is a problem.  You can't just insert <!-- ... --> ANYWHERE in
> HTML. So I had to manually back off and suppress the insertion in
> spots where the comment could confuse an HTML parser, e.g. inside
> comments or inside macros which are officially comments.  If I had a
> tool such as above, that would not be a problem. The generated stream
> would be intact no matter where I made my log entries.
>


Unless you would have some really crappy code most IO calls in an HTML 
generating application would be inside a very small general purpose 
utility class. You would need an entire stack trace at every output 
position to be able to actually pinpoint a bug.
And even then it would only work for simple cases where output would not 
be determined mostly by complex state handled by more or less generic code.

[toc] | [prev] | [next] | [standalone]

#28201

On Wed, 23 Apr 2014 16:46:37 +0200, Silvio <silvio@internet.com>
wrote, quoted or indirectly quoted someone who said :

>Unless you would have some really crappy code most IO calls in an HTML 
>generating application would be inside a very small general purpose 
>utility class. You would need an entire stack trace at every output 
>position to be able to actually pinpoint a bug.

I think, in practice, the depth of the stack you want too sample is
constant.  Perhaps if it is variable, the code would have to set it
dynamically, yuch!  Perhaps the snapshot taker could be given a list
of methods NOT of interest. When it hits one, it snapshots one deeper
in the stack.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

[toc] | [prev] | [next] | [standalone]

#28203

On Wed, 23 Apr 2014 16:46:37 +0200, Silvio <silvio@internet.com>
wrote, quoted or indirectly quoted someone who said :

> You would need an entire stack trace at every output 
>position to be able to actually pinpoint a bug.

I have written this up as a student project.

see http://mindprod.com/project/yadt.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web