Last Comment Bug 950474 - Crash [@ get] due to unhandled OOM in js::RegExpCompartment::getOrCreateMatchResultTemplateObject
: Crash [@ get] due to unhandled OOM in js::RegExpCompartment::getOrCreateMatch...
: crash
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
-- critical (vote)
: mozilla29
Assigned To: Christian Holler (:decoder)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: langfuzz 912928 879402
  Show dependency treegraph
Reported: 2013-12-15 08:56 PST by Christian Holler (:decoder)
Modified: 2014-03-26 02:16 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

js-regexp-oom.patch (1.10 KB, patch)
2013-12-15 08:56 PST, Christian Holler (:decoder)
hv1989: review+
Details | Diff | Splinter Review
patch2 (1.02 KB, patch)
2013-12-16 01:09 PST, Hannes Verschore [:h4writer]
choller: review+
Details | Diff | Splinter Review

Description User image Christian Holler (:decoder) 2013-12-15 08:56:18 PST
Created attachment 8347749 [details] [diff] [review]

I'm seeing a crash that seems to be caused by an unhandled nullptr returned by NewDenseUnallocatedArray in js::RegExpCompartment::getOrCreateMatchResultTemplateObject:

> HeapPtrObject &
> RegExpCompartment::getOrCreateMatchResultTemplateObject(JSContext *cx)
> {
>    /* Create template array object */
>    RootedObject templateObject(cx, NewDenseUnallocatedArray(cx, 0, nullptr, TenuredObject));
>    /* Set dummy index property */
>    RootedValue index(cx, Int32Value(0));
>    if (!baseops::DefineProperty(cx, templateObject, cx->names().index, index,

Looks like templateObject should be checked here. Patch attached.

Regressed by:

commit c60befbddce89cabfab9161a267cff85bd25ad1d
Author:	Hannes Verschore <>  Thu Dec 12 16:43:52 2013
Committer:	Hannes Verschore <> Thu Dec 12 16:43:52 2013

Bug 879402 - Use template object to faster set the input and index properties on CreateRegExpMatchResult, r=bhackett
Comment 1 User image Hannes Verschore [:h4writer] 2013-12-16 01:09:58 PST
Created attachment 8347941 [details] [diff] [review]

I forgot another one, looking at it again.
Comment 2 User image Christian Holler (:decoder) 2013-12-16 03:24:27 PST
Comment on attachment 8347941 [details] [diff] [review]

Looks right :) So are you going to land this and I land my patch?
Comment 3 User image Hannes Verschore [:h4writer] 2013-12-16 05:48:39 PST
Landed both in one commit ;)
Comment 4 User image Ryan VanderMeulen [:RyanVM] 2013-12-16 14:06:06 PST
Comment 5 User image Bogdan Maris, QA [:bogdan_maris] 2014-03-19 06:23:04 PDT
Can we trigger this crash manually on older builds, so we can verify that the crash does not occur in latest builds?
Comment 6 User image Christian Holler (:decoder) 2014-03-19 07:05:33 PDT
For OOM bugs, it's generally not possible to verify that they are gone, even if we have a test. The test can easily not reproduce on a newer build, simply because we don't OOM in the right spot anymore. That said, I haven't seen or hit this anymore in fuzzing or OOM testing, so I'd consider this verified nevertheless :)

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