Bug 59926 – Debugger call frame line numbers are inaccurate if your file contains getter or setter declarations

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Ryan Ackley]

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.

[Ryan Ackley]

Created attachment 91908 [details]
test script used by test.html

[Ryan Ackley]

Created attachment 91985 [details]
patch to fix the bug

[Kevin H McCullough]

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.

[Ryan Ackley]

Strange because I think this was fixed by a change made against another bug.  When is the last time you did a full update?

[Kevin H McCullough]

I'm on r91704.

[Ryan Ackley]

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.

[Gavin Barraclough]

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 ***