This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 138529 - Assertion Error when opening and editing file.
Summary: Assertion Error when opening and editing file.
Status: RESOLVED FIXED
Alias: None
Product: javascript
Classification: Unclassified
Component: Editor (show other bugs)
Version: 6.x
Hardware: Macintosh All
: P2 blocker (vote)
Assignee: Torbjorn Norbye
URL: http://statistics.netbeans.org/analyt...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-27 22:44 UTC by Joelle Lam
Modified: 2009-02-27 14:26 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
When opening this file. I get this AssertionError (62.67 KB, text/plain)
2008-06-27 22:46 UTC, Joelle Lam
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joelle Lam 2008-06-27 22:44:39 UTC
This assertion error continues to come up constantly making it nearly difficult to do any editing with this file.  It
also doesn't happen with all files, just a few.
Comment 1 Joelle Lam 2008-06-27 22:46:04 UTC
Created attachment 63626 [details]
When opening this file.  I get this AssertionError
Comment 2 Joelle Lam 2008-06-27 22:49:26 UTC
Assertion says to assign to Ruby.
Comment 3 Torbjorn Norbye 2008-06-29 18:37:05 UTC
This is a bug in the JavaScript parser.  It's related to position information for E4X. 

The following simple construct will reproduce the problem:
var x = <f={}/>;

(Here's the corresponding construct in the original larger test case:
        var breakpointSetResponse =
            <response command="breakpoint_set"
        state={ disabled ? "disabled" : "enabled"}
        id={href + ":" + line}
        transaction_id={transaction_id} />;
)

The offsets for the E4X nodes are off by one, and this triggers an assertion further up in the parse tree which asserts
that the AST offsets are within certain bounds.

Adjusting category (should be JavaScript; the error reporter probably suggested ruby/gsf because the parser is invoked
from within GSF so the stacktrace-to-bugcategory filter recommended GSF => ruby/gsf).  Also adjusting release since this
was in 6.1 as well and is not new to 6.5.

This bug shouldn't be a problem in official releases however since it's an assertion failure only, and official builds
don't run with assertions enabled.
Comment 4 Torbjorn Norbye 2008-06-29 20:31:06 UTC
Fixed in changeset 5554eb006496.