Closed Bug 194828 Opened 22 years ago Closed 6 years ago

JS_LineNumberToPC doesn't return correct PC

Categories

(Core :: JavaScript Engine, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: rehrlich, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 

When a java script consists or several functions, the JS_LineToPC does not 
return the correct line number for lines within functions. It returns the PC of 
the line after the function in which the line occurs.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Reassigning -

For some reason, I can't find "JS_LineToPC" in the codebase:
http://lxr.mozilla.org/seamonkey/search?string=JS_LineToPC

cc'ing Brendan, rginda for help. What is this? For example,
would it affect the line numbers seen in Venkman? 

Robin: can you say more? What are the steps to reproduce this?
That is, what are you using to inspect output and see this error?
Assignee: rogerl → khanson
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: JS_LineToPC doesn't return correct PC. → JS_LineToPC doesn't return correct PC
Summary: JS_LineToPC doesn't return correct PC → JS_LineNumberToPC doesn't return correct PC
I am creating a debugger for our embedded Javascript system and discovered that 
the procedure JS_LineNumberToPC usually does not return the correct PC. I 
therefore can't set breakpoints within functions. If I have a script that looks 
something like:

function one() {
i=1;
}
function two() {
i=2;
}
i=3;
one();
two();

If I call JS_LineNumberToPC for the line "i=3" on down, the correct PC is 
returned and JS_PCToLineNumber returns the expected line number. If I call 
JS_LineNumberToPC for the line "i=1", I get the PC for "function two()" and If 
I call JS_LineNumberToPC for the line "i=2", I get the PC for "i=3". This is 
verified by calling JS_PCToLineNumber right after calling JS_LineNumberToPC. I 
would imagine Venkman would have the same problem. My guess is that 
js_LineNumberToPC in jsscript.c skips over functions as it looks for the 
matching PC for a line number, but I really don't understand the bytecodes 
emmitted and therefore the logic here.

Thanks for the response so far.
The PC for line 2 (the body of function one, i=1;) is 6, given a script
containing the nine lines of source shown in comment 2.  That PC points to the
nop used as a decompilation placeholder for function one.  The body of function
one is compiled to bytecode in a different script, namely the script owned by
function one.

We could extend JS_LineNumberToPC to check for annotated nops and other function
defining bytecodes, and recursively search for the innermost script most closely
associated with the given line.  But the JS Debugger API has been this way for
years, and I'm loath to change it now.

rginda, what say you?

/be
I'm not sure how that change would work.  Returning a PC that has nothing to do
with the script in question would be of little use.  Are you suggesting we add
something like JS_LineNumberToPCAndScript that could return a script as well as
a PC?

If there is a problem to address here, I think it is that there is no way to
enumerate nested functions for a given script.  Venkman gets around this
limitation with some fancy guesstimation based on the order the scripts were
compiled.

There is also the "legitimate" version of this report, bug 111352.
rginda: yes, we'd have to change the API to return the script in which the pc
was valid, too.  Is it worth it?  Would you rather have a first-class API for
listing functions defined by a script?  Or would you rather have both, to
consolidate code otherwise duplicated among N debuggers that have to enumerate
functions and search for the nearest line?

I don't think this bug is a dup of bug 111352, though.  I commented in that bug
and hope to attach a patch there soon.

/be
> rginda: yes, we'd have to change the API to return the script in which the pc
> was valid, too.  Is it worth it?  Would you rather have a first-class API for
> listing functions defined by a script?  Or would you rather have both, to
> consolidate code otherwise duplicated among N debuggers that have to enumerate
> functions and search for the nearest line?

Both would be great to have, as long as we keep the existing function as-is.

> I don't think this bug is a dup of bug 111352, though.  I commented in that
> bug and hope to attach a patch there soon.

I agree.  I just saw an opportunity to mention the bug :)
Assignee: khanson → general
QA Contact: pschwartau → general
afaik, this function is working now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Resolution: DUPLICATE → FIXED
hmm, wait, I can't tell. I'll leave it open. sorry for the spam.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: general → nobody
JS_LineNumberToPC was removed in bug 1069694, therefore closing as INCOMPLETE.
Status: REOPENED → RESOLVED
Closed: 15 years ago6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.