Closed Bug 440834 Opened 12 years ago Closed 11 years ago

do not cache enumerators when object shape overflowed

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: jorendorff, Assigned: igor)

Details

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

Attachments

(4 files, 2 obsolete files)

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).
Attached file 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
with this patch, the very slow test case only takes a few seconds
(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
Attached patch fix v1 (obsolete) — Splinter Review
Attachment #399104 - Flags: review?(brendan)
Attached patch fix v2 (obsolete) — Splinter Review
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)
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
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

"overflowed"

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,

/be
Attachment #399114 - Flags: review?(brendan) → review+
Attached patch fix v3Splinter Review
fixing English in comments
Attachment #399114 - Attachment is obsolete: true
Attachment #399707 - Flags: review+
Summary: Recover gracefully when rt->shapeGen overflows → do not cache enumerators when object shape overflowed
http://hg.mozilla.org/tracemonkey/rev/7cd82c08ad9e
Whiteboard: [sg:high?] → [sg:high?] fixed-in-tracemonkey
Flags: blocking1.9.2? → blocking1.9.2+
http://hg.mozilla.org/mozilla-central/rev/7cd82c08ad9e
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Priority: -- → P1
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.