276289 - Better error for extremely long array initialiser

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Emanuel Greisen]

When loading a page with a JS-array on one line containing about 10MB of data, I
get an error that the array is not "closed" there is a missing "]".

This is not the case, as the screenshot of the error indicates. It seems that
the buffer reading lines from the document is simply not big enough, thus the
array seems unfinished.

I have "shortened" the array in an other file, and then no error occurs.

Comment 1

[Emanuel Greisen]

Attachment: Contains screenshot of error, and two html-files one with the error one without

Comment 2

[Erik Fabert]

Attachment: testcase

Well, at least using eval() the limit is a lot lower than 10 MB, the script
fails at 196613 characters (6 more than IE6 ;-)).

Warning: the testcase sometimes crashes Firefox/20041229 Win32 for me if the
JavaScript Console is open while it's running. Sorry, no talkback ID, the
talkback agent still can't be installed with this build.

Comment 3

[Erik Fabert]

Doh, there is a 64K limit in place here and each of the elements in my testcase
takes 3 characters, that's why I get 196613 (3*65536+5) as the limit. 

Comment 4

[Boris Zbarsky [:bzbarsky]]

Confirming with current trunk.

Comment 5

[Bob Clary [:bc] (inactive)]

IE fails with out of memory on Erik's test case. Brendan, what say you? Thumbs
down-> wontfix?

Comment 6

[Brendan Eich [:brendan]]

I'd like to diagnose this first.

Crazy amounts of data are flowing as/in JS, these days ("Ajax", donchaknow).  If
we can fix this easily, and you have a lot of RAM, why not?

/be

Comment 7

[Brendan Eich [:brendan]]

This is because of the 16 bit immediate literal index limit, which I've lifted
with the checkin for bug 155081 to a 24 bit (effectively, 23 bits because of
source note representation) limit.  That ought to be enough!

This bug should be morphed, no matter the limit, to ask for a clear diagnostic
that says what the problem is, instead of making a bogus syntax error out of an
array literal too long to fit in the engine's current bytecode representation.

/be

Comment 8

[Brendan Eich [:brendan]]

Fixed; it was obvious and safe for 1.8b2.

/be