Bug 785551 - Do not allow inline JSString chars in the frontend; r=luke

We need direct access to jschar*s in the frontend (and some other places) for
speed, but if these pointers are inlined into JSStrings then a GC may invalidate
them.  This patch ensures that we uninline JSStrings before they enter any of
these regions.
This commit is contained in:
Terrence Cole
2012-08-28 10:28:19 -07:00
parent e9be2dfac7
commit 00d9d36bae
31 changed files with 299 additions and 269 deletions

View File

@@ -263,18 +263,16 @@ AtomizeInline(JSContext *cx, const jschar **pchars, size_t length,
/* Workaround for hash values in AddPtr being inadvertently poisoned. */
SkipRoot skip2(cx, &p);
JSFixedString *key;
JSFlatString *key;
if (ocb == TakeCharOwnership) {
key = js_NewString(cx, const_cast<jschar *>(chars), length);
if (!key)
return NULL;
*pchars = NULL; /* Called should not free *pchars. */
} else {
JS_ASSERT(ocb == CopyChars);
key = js_NewStringCopyN(cx, chars, length);
if (!key)
return NULL;
}
if (!key)
return NULL;
/*
* We have to relookup the key as the last ditch GC invoked from the
@@ -310,11 +308,12 @@ js::AtomizeString(JSContext *cx, JSString *str, InternBehavior ib)
return &atom;
}
size_t length = str->length();
const jschar *chars = str->getChars(cx);
if (!chars)
JSStableString *stable = str->ensureStable(cx);
if (!stable)
return NULL;
const jschar *chars = stable->chars();
size_t length = stable->length();
JS_ASSERT(length <= JSString::MAX_LENGTH);
return AtomizeInline(cx, &chars, length, ib);
}