Bug 59926 - Debugger call frame line numbers are inaccurate if your file contains getter or setter declarations
Summary: Debugger call frame line numbers are inaccurate if your file contains getter ...
Status: RESOLVED DUPLICATE of bug 77675
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P1 Critical
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-02 03:56 PDT by Ryan Ackley
Modified: 2012-03-11 12:33 PDT (History)
3 users (show)

See Also:


Attachments
test file to reproduce the problem (161 bytes, text/html)
2011-05-02 03:56 PDT, Ryan Ackley
no flags Details
test script used by test.html (256 bytes, application/x-javascript)
2011-05-02 03:57 PDT, Ryan Ackley
no flags Details
patch to fix the bug (1.52 KB, patch)
2011-05-02 14:54 PDT, Ryan Ackley
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Ackley 2011-05-02 03:56:03 PDT
Created attachment 91907 [details]
test file to reproduce the problem

If you have a file that uses getter/setter syntax similar to

TestObject.prototype={
  get prop(){
    return 0;
  }
}

The line numbers become skewed in the parser/debugger call frame. For each one of these in your file, the parser seems to add 2 or 3 extra lines to the current line count. 

I first noticed this problem when trying to debug the Web Inspector. It is currently impossible to accurately step through the Web Inspector using the debugger since this syntax is used quite frequently by it.

I've attached a simple test case that reproduces the problem on the nightly build. There is an html file and script. If you set a breakpoint on line 6 of test.html and step into the function call, you will notice that you step into the function a few lines forward from the proper place. I've verified that this line number is being received from the backend and it isn't a bug in the inspector. 

This seems to have been happening for a while. This is probably the cause of Bug 42252.
Comment 1 Ryan Ackley 2011-05-02 03:57:03 PDT
Created attachment 91908 [details]
test script used by test.html
Comment 2 Ryan Ackley 2011-05-02 14:54:13 PDT
Created attachment 91985 [details]
patch to fix the bug
Comment 3 Kevin H McCullough 2011-07-29 10:27:24 PDT
I encountered this problem too, while trying to debug the LeaksParser.  The attached patch fixed it for me, but I don't know enough about the area of code to review it.  It is fairly straightforward though.
Comment 4 Ryan Ackley 2011-07-29 13:31:00 PDT
Strange because I think this was fixed by a change made against another bug.  When is the last time you did a full update?
Comment 5 Kevin H McCullough 2011-07-29 15:04:39 PDT
I'm on r91704.
Comment 6 Ryan Ackley 2011-07-29 15:40:57 PDT
I thought this change might have fixed it 

http://trac.webkit.org/changeset/85456/trunk/Source/JavaScriptCore/parser/JSParser.cpp
 
Sounds like it's not the same fix.
Comment 7 Gavin Barraclough 2012-03-11 12:33:16 PDT
This should be fixed in r106589.  If it's not, please reopen bug#77675, that is now tracking this problem.

cheers,
G.

*** This bug has been marked as a duplicate of bug 77675 ***