1425691 - Assertion failure: !unknownPropertiesDontCheckGeneration(), at js/src/vm/TypeInference-inl.h:1166 with async and debugger

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 4780efa5f110 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe --cpu-count=2 --arm-asm-nop-fill=1 --ion-aa=flow-sensitive):

oomTest(new Function(`
  var g = newGlobal();
  g.eval("(async function* estux() { debugger; })().next();");
`));


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0815ac9e in js::ObjectGroup::maybeGetPropertyDontCheckGeneration (this=0xed5c36a0, id=...) at js/src/vm/TypeInference-inl.h:1166
#0  0x0815ac9e in js::ObjectGroup::maybeGetPropertyDontCheckGeneration (this=0xed5c36a0, id=...) at js/src/vm/TypeInference-inl.h:1166
#1  0x08644607 in js::ObjectGroup::maybeGetProperty (id=..., this=0xed5c36a0) at js/src/vm/TypeInference-inl.h:1182
#2  JSCompartment::getOrCreateIterResultTemplateObject (this=0xefc9c000, cx=0xf6e1d800) at js/src/jsiter.cpp:957
#3  0x0864482a in js::CreateIterResultObject (cx=0xf6e1d800, value=..., done=true) at js/src/jsiter.cpp:904
#4  0x0822d5a2 in AsyncGeneratorResumeNext (cx=0xf6e1d800, asyncGenObj=..., kind=<optimized out>, valueOrException_=..., done=<optimized out>) at js/src/builtin/Promise.cpp:2848
#5  0x0822de7b in js::AsyncGeneratorResolve (cx=0xf6e1d800, asyncGenObj=..., value=..., done=true) at js/src/builtin/Promise.cpp:2775
#6  0x086c11f0 in AsyncGeneratorReturned (value=..., asyncGenObj=..., cx=<optimized out>) at js/src/vm/AsyncIteration.cpp:416
#7  js::AsyncGeneratorResume (cx=0xf6e1d800, asyncGenObj=..., completionKind=js::CompletionKind::Normal, argument=...) at js/src/vm/AsyncIteration.cpp:504
#8  0x0822d9ea in AsyncGeneratorResumeNext (cx=0xf6e1d800, asyncGenObj=..., kind=<optimized out>, valueOrException_=..., done=<optimized out>) at js/src/builtin/Promise.cpp:2963
#9  0x0822edea in js::AsyncGeneratorEnqueue (cx=0xf6e1d800, asyncGenVal=..., completionKind=js::CompletionKind::Normal, completionValue=..., result=...) at js/src/builtin/Promise.cpp:3013
#10 0x086b5ff9 in AsyncGeneratorNext (cx=0xf6e1d800, argc=0, vp=0xf5a500d0) at js/src/vm/AsyncIteration.cpp:236
#11 0x08191ea9 in js::CallJSNative (cx=0xf6e1d800, native=0x86b5fa0 <AsyncGeneratorNext(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:291
#12 0x0818734d in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:473
#13 0x08187710 in InternalCall (cx=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#14 0x0817b538 in js::CallFromStack (args=..., cx=<optimized out>) at js/src/vm/Interpreter.cpp:528
#15 Interpret (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:3096
#16 0x08186f2a in js::RunScript (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:423
#17 0x081894e6 in js::ExecuteKernel (cx=0xf6e1d800, script=..., envChainArg=..., newTargetValue=..., evalInFrame=..., result=0xffffb3c0) at js/src/vm/Interpreter.cpp:706
#18 0x081bbc37 in EvalKernel (cx=0xf6e1d800, v=..., evalType=evalType@entry=INDIRECT_EVAL, caller=..., env=..., pc=0x0, vp=...) at js/src/builtin/Eval.cpp:324
#19 0x081bbf80 in js::IndirectEval (cx=0xf6e1d800, argc=1, vp=0xffffb3c0) at js/src/builtin/Eval.cpp:417
#20 0x08191ea9 in js::CallJSNative (cx=0xf6e1d800, native=0x81bbec0 <js::IndirectEval(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:291
#21 0x0818734d in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:473
#22 0x08187710 in InternalCall (cx=cx@entry=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#23 0x081878ba in js::Call (cx=0xf6e1d800, fval=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:541
#24 0x086b0102 in js::ForwardingProxyHandler::call (this=0x8d983b8 <js::CrossCompartmentWrapper::singleton>, cx=0xf6e1d800, proxy=..., args=...) at js/src/proxy/Wrapper.cpp:176
#25 0x0869e1f2 in js::CrossCompartmentWrapper::call (this=0x8d983b8 <js::CrossCompartmentWrapper::singleton>, cx=0xf6e1d800, wrapper=..., args=...) at js/src/proxy/CrossCompartmentWrapper.cpp:359
#26 0x086980d2 in js::Proxy::call (cx=0xf6e1d800, proxy=..., args=...) at js/src/proxy/Proxy.cpp:511
#27 0x086981a3 in js::proxy_Call (cx=0xf6e1d800, argc=1, vp=0xf5fffec0) at js/src/proxy/Proxy.cpp:770
#28 0x08191ea9 in js::CallJSNative (cx=0xf6e1d800, native=0x8698120 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:291
#29 0x08187662 in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:455
#30 0x08187710 in InternalCall (cx=cx@entry=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#31 0x0818787f in js::CallFromStack (cx=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:528
#32 0x08259ad4 in js::jit::DoCallFallback (cx=0xf6e1d800, frame=0xf5ffff08, stub_=0xf0b9b090, argc=1, vp=0xf5fffec0, res=...) at js/src/jit/BaselineIC.cpp:2559
#33 0x0854d890 in js::jit::Simulator::softwareInterrupt (this=0xf6e59000, instr=0xf6e41f04) at js/src/jit/arm/Simulator-arm.cpp:2672
[...]
#40 0x0835ecfd in js::jit::MaybeEnterJit (cx=0xf6e1d800, state=...) at js/src/jit/Jit.cpp:163
#41 0x08186e65 in js::RunScript (cx=0xf6e1d800, state=...) at js/src/vm/Interpreter.cpp:408
#42 0x08187415 in js::InternalCallOrConstruct (cx=0xf6e1d800, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:495
#43 0x08187710 in InternalCall (cx=cx@entry=0xf6e1d800, args=...) at js/src/vm/Interpreter.cpp:522
#44 0x081878ba in js::Call (cx=0xf6e1d800, fval=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:541
#45 0x0858a0f9 in JS_CallFunction (cx=0xf6e1d800, obj=..., fun=..., args=..., rval=...) at js/src/jsapi.cpp:2954
[...]
#61 main (argc=6, argv=0xffffcdc4, envp=0xffffcde0) at js/src/shell/js.cpp:9040
eax	0x0	0
ebx	0xefc9c001	-271990783
ecx	0xf7d9f864	-136710044
edx	0x0	0
esi	0x8d98ff4	148475892
edi	0xffffa47c	-23428
ebp	0xffffa428	4294943784
esp	0xffffa3f0	4294943728
eip	0x815ac9e <js::ObjectGroup::maybeGetPropertyDontCheckGeneration(jsid)+446>
=> 0x815ac9e <js::ObjectGroup::maybeGetPropertyDontCheckGeneration(jsid)+446>:	movl   $0x0,0x0
   0x815aca8 <js::ObjectGroup::maybeGetPropertyDontCheckGeneration(jsid)+456>:	ud2

Comment 1

[Jason Orendorff [:jorendorff]]

arai, would you please take a look at this?

Code from bug 1394682 is on the stack...

Comment 2

[Tooru Fujisawa [:arai]]

I'll take a look by this weekend.

Comment 3

[Tooru Fujisawa [:arai]]

hiding just in case the info I'm about to write here is critical.

Comment 4

[Tooru Fujisawa [:arai]]

unknownPropertiesDontCheckGeneration checks OBJECT_FLAG_UNKNOWN_PROPERTIES flag:
https://searchfox.org/mozilla-central/rev/a4381ebbdf43f8b054bff49979ddb7298cf4759a/js/src/vm/ObjectGroup.h#371-375
>     bool unknownPropertiesDontCheckGeneration() {
> ...
>         return !!(flagsDontCheckGeneration() & OBJECT_FLAG_UNKNOWN_PROPERTIES);
>     }

the OBJECT_FLAG_UNKNOWN_PROPERTIES flag for the group is set here:
https://searchfox.org/mozilla-central/rev/a4381ebbdf43f8b054bff49979ddb7298cf4759a/js/src/vm/TypeInference.cpp#1993-1994
> static void
> ObjectStateChange(JSContext* cx, ObjectGroup* group, bool markingUnknown)
> {
> ...
>     if (markingUnknown)
>         group->addFlags(OBJECT_FLAG_DYNAMIC_MASK | OBJECT_FLAG_UNKNOWN_PROPERTIES);

in the following backtrace:
0  ObjectStateChange(JSContext*, js::ObjectGroup*, bool) + 189
1  js::ObjectGroup::markUnknown(JSContext*) + 447
2  js::ObjectGroup::getProperty(JSContext*, JSObject*, jsid) + 865
3  js::AddTypePropertyId(JSContext*, js::ObjectGroup*, JSObject*, jsid, js::TypeSet::Type) + 282
4  js::AddTypePropertyId(JSContext*, JSObject*, jsid, js::TypeSet::Type) + 188
5  js::AddTypePropertyId(JSContext*, JSObject*, jsid, JS::Value const&) + 85
6  js::NativeObject::setSlotWithType(JSContext*, js::Shape*, JS::Value const&, bool) + 147
7  UpdateShapeTypeAndValue(JSContext*, js::NativeObject*, js::Shape*, jsid, JS::Value const&) + 172
8  bool AddOrChangeProperty<(IsAddOrChange)0>(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JS::PropertyDescriptor>) + 1085
9  js::NativeDefineProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JS::PropertyDescriptor>, JS::ObjectOpResult&) + 2128
10 js::NativeDefineDataProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JS::Value>, unsigned int, JS::ObjectOpResult&) + 211
11 js::NativeDefineDataProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<jsid>, JS::Handle<JS::Value>, unsigned int) + 96
12 js::NativeDefineDataProperty(JSContext*, JS::Handle<js::NativeObject*>, js::PropertyName*, JS::Handle<JS::Value>, unsigned int) + 122
13 JSCompartment::getOrCreateIterResultTemplateObject(JSContext*) + 650
14 js::CreateIterResultObject(JSContext*, JS::Handle<JS::Value>, bool) + 47
15 AsyncGeneratorResumeNext(JSContext*, JS::Handle<js::AsyncGeneratorObject*>, ResumeNextKind, JS::Handle<JS::Value>, bool) + 937
16 js::AsyncGeneratorResolve(JSContext*, JS::Handle<js::AsyncGeneratorObject*>, JS::Handle<JS::Value>, bool) + 84
17 AsyncGeneratorReturned(JSContext*, JS::Handle<js::AsyncGeneratorObject*>, JS::Handle<JS::Value>) + 78
18 js::AsyncGeneratorResume(JSContext*, JS::Handle<js::AsyncGeneratorObject*>, js::CompletionKind, JS::Handle<JS::Value>) + 1011
19 AsyncGeneratorResumeNext(JSContext*, JS::Handle<js::AsyncGeneratorObject*>, ResumeNextKind, JS::Handle<JS::Value>, bool) + 2900
20 js::AsyncGeneratorEnqueue(JSContext*, JS::Handle<JS::Value>, js::CompletionKind, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) + 850
21 AsyncGeneratorNext(JSContext*, unsigned int, JS::Value*) + 120
22 js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 132
23 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) + 1135
24 InternalCall(JSContext*, js::AnyInvokeArgs const&) + 496
25 js::CallFromStack(JSContext*, JS::CallArgs const&) + 29
26 Interpret(JSContext*, js::RunState&) + 44540
27 js::RunScript(JSContext*, js::RunState&) + 983
28 js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::AbstractFramePtr, JS::Value*) + 755
29 EvalKernel(JSContext*, JS::Handle<JS::Value>, EvalType, js::AbstractFramePtr, JS::Handle<JSObject*>, unsigned char*, JS::MutableHandle<JS::Value>) + 2899
30 js::IndirectEval(JSContext*, unsigned int, JS::Value*) + 252
31 js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 132
32 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) + 1135
33 InternalCall(JSContext*, js::AnyInvokeArgs const&) + 496
34 js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) + 102
35 js::ForwardingProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) const + 384
36 js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) const + 463
37 js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) + 360
38 js::proxy_Call(JSContext*, unsigned int, JS::Value*) + 216
39 js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) + 132
40 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) + 672
41 InternalCall(JSContext*, js::AnyInvokeArgs const&) + 496
42 js::CallFromStack(JSContext*, JS::CallArgs const&) + 29
43 js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) + 3075

Comment 5

[Tooru Fujisawa [:arai]]

so I think some of the conditions for calling markUnknown in the following method is related:
https://searchfox.org/mozilla-central/rev/a4381ebbdf43f8b054bff49979ddb7298cf4759a/js/src/vm/TypeInference-inl.h#1117-1159

now tracing.

Comment 6

[Tooru Fujisawa [:arai]]

`new_` call here fails because of OOM, and in that case the assumption in getOrCreateIterResultTemplateObject breaks.

https://searchfox.org/mozilla-central/rev/a4381ebbdf43f8b054bff49979ddb7298cf4759a/js/src/vm/TypeInference-inl.h#1129
> inline HeapTypeSet*
> ObjectGroup::getProperty(JSContext* cx, JSObject* obj, jsid id)
> {
> ...
>     Property* base = cx->typeLifoAlloc().new_<Property>(id);
>     if (!base) {
>         markUnknown(cx);
>         return nullptr;
>     }

+ js::CreateIterResultObject
  + JSCompartment::getOrCreateIterResultTemplateObject
  | + js::NativeDefineDataProperty
  |   + js::NativeDefineDataProperty
  |     + js::NativeDefineDataProperty
  |       + js::NativeDefineProperty
  |         + AddOrChangeProperty
  |           + UpdateShapeTypeAndValue
  |             + js::NativeObject::setSlotWithType
  |               + js::AddTypePropertyId
  |                 + js::AddTypePropertyId
  |                   + js::AddTypePropertyId
  |                     + js::ObjectGroup::getProperty
  |                       + js::ObjectGroup::markUnknown
  |                         + ObjectStateChange
  |                           sets OBJECT_FLAG_UNKNOWN_PROPERTIES here
  |
  + JSCompartment::getOrCreateIterResultTemplateObject
    + js::ObjectGroup::maybeGetProperty
      + js::ObjectGroup::maybeGetPropertyDontCheckGeneration
        + js::ObjectGroup::unknownPropertiesDontCheckGeneration
          returns true because OBJECT_FLAG_UNKNOWN_PROPERTIES is set

maybe we should fallback to slower way, or propagate OOM?

Comment 7

[Tooru Fujisawa [:arai]]

uh, the tree was wrong

+ js::CreateIterResultObject
  + JSCompartment::getOrCreateIterResultTemplateObject
    + js::NativeDefineDataProperty
    | + js::NativeDefineDataProperty
    |   + js::NativeDefineDataProperty
    |     + js::NativeDefineProperty
    |       + AddOrChangeProperty
    |         + UpdateShapeTypeAndValue
    |           + js::NativeObject::setSlotWithType
    |             + js::AddTypePropertyId
    |               + js::AddTypePropertyId
    |                 + js::AddTypePropertyId
    |                   + js::ObjectGroup::getProperty
    |                     + js::ObjectGroup::markUnknown
    |                       + ObjectStateChange
    |                         sets OBJECT_FLAG_UNKNOWN_PROPERTIES here
    |
    + js::ObjectGroup::maybeGetProperty
      + js::ObjectGroup::maybeGetPropertyDontCheckGeneration
        + js::ObjectGroup::unknownPropertiesDontCheckGeneration
          returns true because OBJECT_FLAG_UNKNOWN_PROPERTIES is set

Comment 8

[Tooru Fujisawa [:arai]]

I'll go with propagating OOM.

Comment 9

[Tooru Fujisawa [:arai]]

Attachment: Propagate OOM while creating iterator result template object.

The code added in bug 1394682 heavily depends on the template object,
and adding workaround for the broken template object case will regress the performance.
so I'd like to propagate the OOM happens inside ObjectGroup, and just throw away the broken template object.

I added the testcase from comment #0, but it hits tiemout locally, so I added slow flag.

Comment 10

[Jan de Mooij [:jandem]]

Comment on attachment 8942547 [details] [diff] [review]
Propagate OOM while creating iterator result template object.

Review of attachment 8942547 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think we should assume unknown properties means OOM - in theory we could mark all groups as having unknown properties and things should still work.

Is the problem the maybeGetProperty call here [0]? I'd suggest just wrapping that code in if (!group->unknownProperties()) { ... }

[0] https://searchfox.org/mozilla-central/rev/48cbb200aa027a0a379b6004b6196a167344b865/js/src/jsiter.cpp#957-962

Comment 11

[Andrew McCreight [:mccr8]]

I'm going to be conservative and mark this sec-high. Feel free to adjust.

Comment 12

[Tooru Fujisawa [:arai]]

(In reply to Jan de Mooij [:jandem] from comment #10)
> Comment on attachment 8942547 [details] [diff] [review]
> Propagate OOM while creating iterator result template object.
> 
> Review of attachment 8942547 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I don't think we should assume unknown properties means OOM - in theory we
> could mark all groups as having unknown properties and things should still
> work.
> 
> Is the problem the maybeGetProperty call here [0]? I'd suggest just wrapping
> that code in if (!group->unknownProperties()) { ... }

So, we can use the template object?

I confirmed the object's shape is in correct state even after the OOM.
but the type is not in expected state (that is, "value" property is unknown, "done" property is boolean).
does it just result in non-optimized executed, instead of crash or something?

Comment 13

[Tooru Fujisawa [:arai]]

Attachment: Do not update type information of iter result object template if the object group has unknown properties.

so far, this patch surely fixes the crash.

Comment 14

[Jan de Mooij [:jandem]]

Comment on attachment 8943988 [details] [diff] [review]
Do not update type information of iter result object template if the object group has unknown properties.

Review of attachment 8943988 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah this patch looks correct. If the group has unknownProperties() it means all properties have unknown types, so the makeUnknown() call would be redundant.

Comment 15

[Tooru Fujisawa [:arai]]

Comment on attachment 8943988 [details] [diff] [review]
Do not update type information of iter result object template if the object group has unknown properties.

This results in just a null-dereference at this line, because `types` is nullptr, on non-debug built:

https://searchfox.org/mozilla-central/rev/b7e3ec2468d42fa59d86c03ec7afeb209813f1d4/js/src/jsiter.cpp#961
> types->makeUnknown(cx);

asking sec-approval just for clarification, since this bug has sec-high label.


[Security approval request comment]
> How easily could an exploit be constructed based on the patch?
a website that crashes browser may be constructed easily,
but it will take so long runtime to hit it.

> Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
the code change may tell something, but not directly.

> Which older supported branches are affected by this flaw?
57

> If not all supported branches, which bug introduced the flaw?
bug 1394682

> Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
not yet, but the same patch (maybe with minor fix) should be applicable.

> How likely is this patch to cause regressions; how much testing does it need?
not likely.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

We don't allow tests in patches that need sec-approval for sec-high and sec-critical issues because tests demonstrating a vulnerability can't land until we ship the security fix to all affected versions (and really not until about a month after). Can you please split the test out of the patch?

Comment 17

[Tooru Fujisawa [:arai]]

Attachment: Do not update type information of iter result object template if the object group has unknown properties. r=jandem

(In reply to Al Billings [:abillings] from comment #16)
> We don't allow tests in patches that need sec-approval for sec-high and
> sec-critical issues because tests demonstrating a vulnerability can't land
> until we ship the security fix to all affected versions (and really not
> until about a month after). Can you please split the test out of the patch?

okay, here is the patch without the test

Comment 18

[Tooru Fujisawa [:arai]]

Attachment: (do not land this now) Part 2: Add testcase. r=jandem

Comment 19

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8945606 [details] [diff] [review]
Do not update type information of iter result object template if the object group has unknown properties. r=jandem

sec-approval+

Comment 20

[Tooru Fujisawa [:arai]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc126cc0f071493c13b1d6bd3eccfdb7b184f075
Bug 1425691 - Do not update type information of iter result object template if the object group has unknown properties. r=jandem

Comment 21

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/cc126cc0f071

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Please request Beta approval on this patch when you get a chance. It grafts cleanly as-landed.

Comment 23

[Tooru Fujisawa [:arai]]

Comment on attachment 8945606 [details] [diff] [review]
Do not update type information of iter result object template if the object group has unknown properties. r=jandem

Approval Request Comment
> [Feature/Bug causing the regression]
bug 1394682

> [User impact if declined]
Possible crash by opening a webpage, but it will take long time running JS code

> [Is this code covered by automated tests?]
No.
there's testcase but it's not landed,
and also it's disabled since it always hits timeout.

> [Has the fix been verified in Nightly?]
Yes

> [Needs manual test from QE? If yes, steps to reproduce]
No

> [List of other uplifts needed for the feature/fix]
None

> [Is the change risky?]
No

> [Why is the change risky/not risky?]
If just fallbacks to unoptimized execution

> [String changes made/needed]
None

Comment 24

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8945606 [details] [diff] [review]
Do not update type information of iter result object template if the object group has unknown properties. r=jandem

Fix for sec-high issue/potential crash, has sec approval. Let's uplift for 59 beta 6.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e6146cc17bec