do not cache enumerators when object shape overflowed




JavaScript Engine
9 years ago
6 years ago


(Reporter: jorendorff, Assigned: Igor Bukanov)


Bug Flags:
blocking1.9.2 +
wanted1.9.0.x ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed, blocking1.9.1 needed, status1.9.1 wanted)


(Whiteboard: [sg:high?] fixed-in-tracemonkey [needs answer to comment 13, esp the 503080 part])


(4 attachments, 2 obsolete attachments)



9 years ago
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).
Created attachment 398048 [details]
stacktrace of assertion failure
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.
Attachment #398050 - Attachment mime type: text/html → text/plain
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

8 years ago
(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.
Assignee: general → igor

Comment 5

8 years ago
Created attachment 399104 [details] [diff] [review]
fix v1
Attachment #399104 - Flags: review?(brendan)

Comment 6

8 years ago
Created attachment 399114 [details] [diff] [review]
fix v2

In the previous patch I missed another case of storing overflown shape into the cache.
Attachment #399104 - Attachment is obsolete: true
Attachment #399114 - Flags: review?(brendan)
Attachment #399104 - Flags: review?(brendan)

Comment 7

8 years ago
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.
Group: core-security
Flags: wanted1.9.0.x?
Flags: blocking1.9.2?
blocking1.9.1: --- → needed
status1.9.1: --- → wanted
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Whiteboard: [sg:high?]
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,

Attachment #399114 - Flags: review?(brendan) → review+

Comment 9

8 years ago
Created attachment 399707 [details] [diff] [review]
fix v3

fixing English in comments
Attachment #399114 - Attachment is obsolete: true
Attachment #399707 - Flags: review+


8 years ago
Summary: Recover gracefully when rt->shapeGen overflows → do not cache enumerators when object shape overflowed

Comment 10

8 years ago
Whiteboard: [sg:high?] → [sg:high?] fixed-in-tracemonkey


8 years ago
Flags: blocking1.9.2? → blocking1.9.2+
Last Resolved: 8 years ago
Resolution: --- → FIXED


8 years ago
Priority: -- → P1

Comment 12

8 years ago
status1.9.2: --- → beta1-fixed
blocking1.9.1: needed → .5+
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?)
blocking1.9.1: .6+ → needed
Flags: wanted1.9.0.x+ → wanted1.9.0.x?
Whiteboard: [sg:high?] fixed-in-tracemonkey → [sg:high?] fixed-in-tracemonkey [needs answer to comment 13, esp the 503080 part]
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?
Group: core-security
You need to log in before you can comment on or make changes to this bug.