Last Comment Bug 440834 - do not cache enumerators when object shape overflowed
: do not cache enumerators when object shape overflowed
[sg:high?] fixed-in-tracemonkey [need...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
P1 normal (vote)
: ---
Assigned To: Igor Bukanov
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2008-06-20 13:20 PDT by Jason Orendorff [:jorendorff]
Modified: 2011-09-26 23:31 PDT (History)
8 users (show)
sayrer: blocking1.9.2+
dveditz: wanted1.9.0.x?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stacktrace of assertion failure (5.72 KB, text/plain)
2009-09-01 17:50 PDT, David Keeler [:keeler] (use needinfo?)
no flags Details
very slow testcase (136 bytes, text/plain)
2009-09-01 17:53 PDT, David Keeler [:keeler] (use needinfo?)
no flags Details
patch to make overflow happen faster (1.00 KB, patch)
2009-09-02 11:54 PDT, David Keeler [:keeler] (use needinfo?)
no flags Details | Diff | Splinter Review
fix v1 (2.69 KB, patch)
2009-09-07 13:32 PDT, Igor Bukanov
no flags Details | Diff | Splinter Review
fix v2 (3.78 KB, patch)
2009-09-07 14:22 PDT, Igor Bukanov
brendan: review+
Details | Diff | Splinter Review
fix v3 (3.80 KB, patch)
2009-09-10 04:55 PDT, Igor Bukanov
igor: review+
Details | Diff | Splinter Review

Description User image Jason Orendorff [:jorendorff] 2008-06-20 13:20:38 PDT
This came up in bug 419091 comment 17 through 21.

If a program manages to overflow rt->shapeGen, SpiderMonkey should disable the property cache (runtime-wide) and run without it until such time as shapes are GC'd to reduce the total number of shapes to less 2**24.

Currently the property cache is permanently disabled if this happens, and GC starts happening very frequently (from js_GenerateShape).
Comment 1 User image David Keeler [:keeler] (use needinfo?) 2009-09-01 17:50:03 PDT
Created attachment 398048 [details]
stacktrace of assertion failure
Comment 2 User image David Keeler [:keeler] (use needinfo?) 2009-09-01 17:53:47 PDT
Created attachment 398050 [details]
very slow testcase

This is the original, very slow test case (it takes ~1 hour on my machine).  I'm working on a faster one.
Comment 3 User image David Keeler [:keeler] (use needinfo?) 2009-09-02 11:54:21 PDT
Created attachment 398193 [details] [diff] [review]
patch to make overflow happen faster

with this patch, the very slow test case only takes a few seconds
Comment 4 User image Igor Bukanov 2009-09-06 03:16:18 PDT
(In reply to comment #1)
> Created an attachment (id=398048) [details]
> stacktrace of assertion failure

The stack indicates that the native enumerators should not be cached when shape overflows.
Comment 5 User image Igor Bukanov 2009-09-07 13:32:11 PDT
Created attachment 399104 [details] [diff] [review]
fix v1
Comment 6 User image Igor Bukanov 2009-09-07 14:22:54 PDT
Created attachment 399114 [details] [diff] [review]
fix v2

In the previous patch I missed another case of storing overflown shape into the cache.
Comment 7 User image Igor Bukanov 2009-09-09 06:27:50 PDT
I mark this bug as restrictive for now. It could be used to change the enumeration property list for for-in loops via caching with overflown shape some preset lists potentially leading to XSS and other attacks.
Comment 8 User image Brendan Eich [:brendan] 2009-09-09 15:45:42 PDT
Comment on attachment 399114 [details] [diff] [review]
fix v2

>@@ -5028,17 +5031,23 @@ js_Enumerate(JSContext *cx, JSObject *ob
>                 if (!js_AddAsGCBytes(cx, allocated)) {
>                     /* js_AddAsGCBytes releases the GC lock on failures. */
>                     cx->free(ne);
>                     return JS_FALSE;
>                 }
>                 ne->next = cx->runtime->nativeEnumerators;
>                 cx->runtime->nativeEnumerators = ne;
>                 JS_ASSERT(((jsuword) ne & (jsuword) 1) == (jsuword) 0);
>-                *cachep = (jsuword) ne;
>+                /*
>+                 * Do not cache enumerators for objects with an overflown


fly/flew/[have|had] flown != overflow/overflowed/[have|had] overflowed

Ain't English grand? :-P

So "with a shape that had overflowed" might be better, but your sentence structure (with the word fixed) is fine comment-speak.

r=me with this fixed. Thanks,

Comment 9 User image Igor Bukanov 2009-09-10 04:55:57 PDT
Created attachment 399707 [details] [diff] [review]
fix v3

fixing English in comments
Comment 11 User image Blake Kaplan (:mrbkap) 2009-09-16 17:35:27 PDT
Comment 13 User image Samuel Sidler (old account; do not CC) 2009-11-04 17:26:50 PST
Does this patch apply to 1.9.1? If so, can you please request approval? If not, please attach a patch that does apply and request approval. Code freeze is currently scheduled for November 10 at 11:59pm.

(Or does this bug require some part of the bug 503080 and its dependencies?)
Comment 14 User image Daniel Veditz [:dveditz] 2010-10-18 10:43:26 PDT
Comment 7 is still worrying -- does this patch work for the 1.9.1 branch or does it require any part of the big set of changes/regressions in bug 503080?

Note You need to log in before you can comment on or make changes to this bug.