Bug 23089 – [jsfunfuzz] tostring on large array causes oom hang/crash

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: JavaScriptCore

[Oliver Hunt]

switch(+(Array(2147483647))){default:}

[Oliver Hunt]

Firefox produces a slow script warning on this example, we don't because Array.toString, etc are native code.

I'm thinking that a hard cap on toString'd array size + time out checks periodically in the toString conversion and what not would do the trick.  Anyone have any better ideas?

[Oliver Hunt]

Hmmm, it occurs to me that relying on the slow script dialog to kill execution won't work in the shell.

Also the code has a null check of the data for the buffer (to catch OOM) but vector growing uses the crashing version of malloc

Is it possible to make a vector use the non-throwing version?

[Oliver Hunt]

Also, for reference a JS version of Array.toString solves the hang by implicitly having timeout checks.  unfortunately it's 35% slower than the C++ version.  For compact (non-sparse) arrays it beats firefox though :D

[Darin Adler]

(In reply to comment #2)
> Is it possible to make a vector use the non-throwing version?

Sure it's possible, but it changes the contract with clients.

What behavior are you suggesting when allocation fails? How will we update all the clients to work with the new behavior?

[Oliver Hunt]

(In reply to comment #4)
> (In reply to comment #2)
> > Is it possible to make a vector use the non-throwing version?
> 
> Sure it's possible, but it changes the contract with clients.
> 
> What behavior are you suggesting when allocation fails? How will we update all
> the clients to work with the new behavior?
> 

No i dind't mean in general --i was asking (somewhat vaguely i guess)  whether there a template parameter or something that control which malloc a vector would use.

[Darin Adler]

(In reply to comment #5)
> No i dind't mean in general --i was asking (somewhat vaguely i guess)  whether
> there a template parameter or something that control which malloc a vector
> would use.

Sure, we could. But then we'd still need to define what various operations do when allocation fails when that template parameter was set.

It might be better to have a completely separate class template. We could still share implementation with Vector.

[Gavin Barraclough]

*** Bug 13638 has been marked as a duplicate of this bug. ***

[Gavin Barraclough]

This test case is equivalent to Array(2147483647).toString().  This completes with appropriate performance.  Works for me.