Strange behaviour on stepping.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange behaviour on stepping.

dassburger (Bugzilla)
Hello!

One more question from me. Suppose we have the following script:

===================================================
1:   var x = 5;
2:
3:   Log.WriteLine('1');
4:
5:   x = x + 2;
6:
7:   var y = x + 3;
8:   Log.WriteLine('2');
===================================================

First, I set an execution hook at line 1, start the script. Then I add
an interrupt hook and return from execution hook handler. I see a
strange behaviour. SpiderMonkey seems to pass the script twice, first,
it only stops at lines 1 and 7. Then it starts to execute the script as
usual, line by line: 3, 5, 7, 8.

If I put an execution hook at line 3 and start the script, it'll stop
at line 7. Continuing the execution will result in no stop at line 3.
However, if I'll step from no on, it will go by lines 7, 1, 3, 5, 7, 8.

The question is, is it the intended behaviour? How can I implement
stepping and tracing around the code in my debugger so, that a user
will not notice the first pass?

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

James Ross
Dassburger wrote:

> Hello!
>
> One more question from me. Suppose we have the following script:
>
> ===================================================
> 1:   var x = 5;
> 2:
> 3:   Log.WriteLine('1');
> 4:
> 5:   x = x + 2;
> 6:
> 7:   var y = x + 3;
> 8:   Log.WriteLine('2');
> ===================================================
>
> First, I set an execution hook at line 1, start the script. Then I add
> an interrupt hook and return from execution hook handler. I see a
> strange behaviour. SpiderMonkey seems to pass the script twice, first,
> it only stops at lines 1 and 7. Then it starts to execute the script as
> usual, line by line: 3, 5, 7, 8.

Is that the exact script used? I ask because if you have functions, you
will get an execution hook for each function declaration in the
top-level script as that is run (even if there's no code outside functions).

If it is the exact script used, can you try dumping all the PC values
through a single run? I'm interested in whether the places it stops on
line 1 and 7 are PC values that it hits again during the 'real' run.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

dassburger (Bugzilla)
James Ross wrote:

> Dassburger wrote:
> > Hello!
> >
> > One more question from me. Suppose we have the following script:
> >
> > ===================================================
> > 1:   var x = 5;
> > 2:
> > 3:   Log.WriteLine('1');
> > 4:
> > 5:   x = x + 2;
> > 6:
> > 7:   var y = x + 3;
> > 8:   Log.WriteLine('2');
> > ===================================================
> >
> > First, I set an execution hook at line 1, start the script. Then I add
> > an interrupt hook and return from execution hook handler. I see a
> > strange behaviour. SpiderMonkey seems to pass the script twice, first,
> > it only stops at lines 1 and 7. Then it starts to execute the script as
> > usual, line by line: 3, 5, 7, 8.
>
> Is that the exact script used? I ask because if you have functions, you
> will get an execution hook for each function declaration in the
> top-level script as that is run (even if there's no code outside functions).

This is the exact test script. I already noticed the behaviour of JSD
when it meets functions. It, surely, will make a user to scratch
his/her head a little bit, but we can live with it.

> If it is the exact script used, can you try dumping all the PC values
> through a single run? I'm interested in whether the places it stops on
> line 1 and 7 are PC values that it hits again during the 'real' run.

They differ. For example, pass 1 gives such:

1: 80640600
7: 80640603

and pass 2 gives such:

1: 80640606
7: 80640644

The sequence of calls JSD_GetPCForStackFrame() -> JSD_GetClosestLine()
however returns line numbers 1 and 7 on both passes.

> --
> James Ross <[hidden email]>
> ChatZilla Developer

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

James Ross
Dassburger wrote:

> They differ. For example, pass 1 gives such:
>
> 1: 80640600
> 7: 80640603
>
> and pass 2 gives such:
>
> 1: 80640606
> 7: 80640644
>
> The sequence of calls JSD_GetPCForStackFrame() -> JSD_GetClosestLine()
> however returns line numbers 1 and 7 on both passes.

Very interesting. I'd ask you to give the decomplication of the script's
annotations (or even the script's bytecode itself), but I don't know of
a way to do that.

I'll have a poke about locally later with my debugger, but there is one
thing you could try: add/remove/move the |var| lines. It seems a bit too
coincidental that the two lines it jumps to are the var lines.

--
James Ross <[hidden email]>
ChatZilla Developer
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

Randy D. Smith
Isn't this all just the "normal expected behavior" as documented in <
http://article.gmane.org/gmane.comp.mozilla.devel.jsdebugger/688
>? When I was trying to come up to speed on Venkman, I read through that
newsgroup and this thread brought to mind the "What do people use Venkman
for?" thread. I suggest reading through it to see that the two pass approach
is "per the standard" according to the claims there.
--
     RDS


On 8/2/06, James Ross <[hidden email]> wrote:

>
> Dassburger wrote:
> > They differ. For example, pass 1 gives such:
> >
> > 1: 80640600
> > 7: 80640603
> >
> > and pass 2 gives such:
> >
> > 1: 80640606
> > 7: 80640644
> >
> > The sequence of calls JSD_GetPCForStackFrame() -> JSD_GetClosestLine()
> > however returns line numbers 1 and 7 on both passes.
>
> Very interesting. I'd ask you to give the decomplication of the script's
> annotations (or even the script's bytecode itself), but I don't know of
> a way to do that.
>
> I'll have a poke about locally later with my debugger, but there is one
> thing you could try: add/remove/move the |var| lines. It seems a bit too
> coincidental that the two lines it jumps to are the var lines.
>
> --
> James Ross <[hidden email]>
> ChatZilla Developer
> _______________________________________________
> dev-apps-js-debugger mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-js-debugger
>
_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

dassburger (Bugzilla)
In reply to this post by James Ross

Randy D. Smith wrote:
> Isn't this all just the "normal expected behavior" as documented in <
> http://article.gmane.org/gmane.comp.mozilla.devel.jsdebugger/688
> >? When I was trying to come up to speed on Venkman, I read through that
> newsgroup and this thread brought to mind the "What do people use Venkman
> for?" thread. I suggest reading through it to see that the two pass approach
> is "per the standard" according to the claims there.
> --
>      RDS

Very interesting! It really seemed to me that this is somewhat related
with creation of variables. But another question arises - is there some
way to determine the state of the interpretator in a hook handler? I'm
starting to look for it, but it would be great if someone old,
long-white-bearded, and knowledgeful gave me some ideas. :-)

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

dassburger (Bugzilla)

Dassburger wrote:

> Randy D. Smith wrote:
> > Isn't this all just the "normal expected behavior" as documented in <
> > http://article.gmane.org/gmane.comp.mozilla.devel.jsdebugger/688
> > >? When I was trying to come up to speed on Venkman, I read through that
> > newsgroup and this thread brought to mind the "What do people use Venkman
> > for?" thread. I suggest reading through it to see that the two pass approach
> > is "per the standard" according to the claims there.
> > --
> >      RDS
>
> Very interesting! It really seemed to me that this is somewhat related
> with creation of variables. But another question arises - is there some
> way to determine the state of the interpretator in a hook handler? I'm
> starting to look for it, but it would be great if someone old,
> long-white-bearded, and knowledgeful gave me some ideas. :-)

The probem is solved! When compiling a script SpiderMonkey puts
bytecode which creates global vars and sets them undefined value first.
Then goes the actual bytecode. The problem is that initialization code
has the same line numbers where vars are declared. JSD_GetClosestPC()
looks through the bytecode and stops searching when instruction's line
number is equal or greater than its argument. If argument is between
two "var" declarations, it will return wrong PC. I propose to define)
js_LineNumberToPC() as follows:

jsbytecode *
js_LineNumberToPC(JSScript *script, uintN target)
{
    ptrdiff_t offset;
    uintN lineno;
    jssrcnote *sn;
    JSSrcNoteType type;
    jsbytecode *pc_with_min_lineno_diff=0;   // dassb.
    uintN min_lineno_diff = INT_MAX;         // dassb.

    offset = 0;
    lineno = script->lineno;
    for (sn = SCRIPT_NOTES(script); !SN_IS_TERMINATOR(sn); sn =
SN_NEXT(sn)) {
        if (lineno >= target && (lineno - target) < min_lineno_diff) {
//dassb.
          min_lineno_diff = lineno - target;
//dassb.
          pc_with_min_lineno_diff = script->code + offset;
//dassb.
        }
//dassb.
        offset += SN_DELTA(sn);
        type = (JSSrcNoteType) SN_TYPE(sn);
        if (type == SRC_SETLINE) {
            lineno = (uintN) js_GetSrcNoteOffset(sn, 0);
        } else if (type == SRC_NEWLINE) {
            lineno++;
        }
    }
    return pc_with_min_lineno_diff;
}

_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour on stepping.

Mike Moening
I had the same problem a while back....
See bug:  https://bugzilla.mozilla.org/show_bug.cgi?id=313922

"Dassburger" <[hidden email]> wrote in message
news:[hidden email]...
>
> Dassburger wrote:
> > Randy D. Smith wrote:
> > > Isn't this all just the "normal expected behavior" as documented in <
> > > http://article.gmane.org/gmane.comp.mozilla.devel.jsdebugger/688
> > > >? When I was trying to come up to speed on Venkman, I read through
that
> > > newsgroup and this thread brought to mind the "What do people use
Venkman
> > > for?" thread. I suggest reading through it to see that the two pass
approach

> > > is "per the standard" according to the claims there.
> > > --
> > >      RDS
> >
> > Very interesting! It really seemed to me that this is somewhat related
> > with creation of variables. But another question arises - is there some
> > way to determine the state of the interpretator in a hook handler? I'm
> > starting to look for it, but it would be great if someone old,
> > long-white-bearded, and knowledgeful gave me some ideas. :-)
>
> The probem is solved! When compiling a script SpiderMonkey puts
> bytecode which creates global vars and sets them undefined value first.
> Then goes the actual bytecode. The problem is that initialization code
> has the same line numbers where vars are declared. JSD_GetClosestPC()
> looks through the bytecode and stops searching when instruction's line
> number is equal or greater than its argument. If argument is between
> two "var" declarations, it will return wrong PC. I propose to define)
> js_LineNumberToPC() as follows:
>
> jsbytecode *
> js_LineNumberToPC(JSScript *script, uintN target)
> {
>     ptrdiff_t offset;
>     uintN lineno;
>     jssrcnote *sn;
>     JSSrcNoteType type;
>     jsbytecode *pc_with_min_lineno_diff=0;   // dassb.
>     uintN min_lineno_diff = INT_MAX;         // dassb.
>
>     offset = 0;
>     lineno = script->lineno;
>     for (sn = SCRIPT_NOTES(script); !SN_IS_TERMINATOR(sn); sn =
> SN_NEXT(sn)) {
>         if (lineno >= target && (lineno - target) < min_lineno_diff) {
> //dassb.
>           min_lineno_diff = lineno - target;
> //dassb.
>           pc_with_min_lineno_diff = script->code + offset;
> //dassb.
>         }
> //dassb.
>         offset += SN_DELTA(sn);
>         type = (JSSrcNoteType) SN_TYPE(sn);
>         if (type == SRC_SETLINE) {
>             lineno = (uintN) js_GetSrcNoteOffset(sn, 0);
>         } else if (type == SRC_NEWLINE) {
>             lineno++;
>         }
>     }
>     return pc_with_min_lineno_diff;
> }
>


_______________________________________________
dev-apps-js-debugger mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-js-debugger