Closed
Bug 194828
Opened 22 years ago
Closed 6 years ago
JS_LineNumberToPC doesn't return correct PC
Categories
(Core :: JavaScript Engine, defect)
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.
Comment 1•22 years ago
|
||
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
Reporter | ||
Comment 2•22 years ago
|
||
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.
Comment 3•22 years ago
|
||
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
Comment 4•22 years ago
|
||
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.
Comment 5•22 years ago
|
||
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
Comment 6•22 years ago
|
||
> 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 :)
Updated•19 years ago
|
Assignee: khanson → general
QA Contact: pschwartau → general
Comment 7•15 years ago
|
||
afaik, this function is working now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Resolution: DUPLICATE → FIXED
Comment 8•15 years ago
|
||
hmm, wait, I can't tell. I'll leave it open. sorry for the spam.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Comment 9•6 years ago
|
||
JS_LineNumberToPC was removed in bug 1069694, therefore closing as INCOMPLETE.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 6 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•