834240 - Crash [@ sizeOfThis] or Crash [@ CheckMarkedThing] due to OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

During fuzzing I found the following crash on mozilla-central revision 98ea4d294369:

Program received signal SIGSEGV, Segmentation fault.
sizeOfThis (this=0xfff9800000000001) at /srv/repos/mozilla-central/js/src/vm/ObjectImpl-inl.h:370
370         return arenaHeader()->getThingSize();
(gdb) bt
#0  sizeOfThis (this=0xfff9800000000001) at /srv/repos/mozilla-central/js/src/vm/ObjectImpl-inl.h:370
#1  copyCachedToObject (src=(JSObject *) 0x7ffff7e53fd0 [object Object], dst=(JSObject *) 0xfff9800000000001 Cannot access memory at address 0xfff9800000000001)
    at /srv/repos/mozilla-central/js/src/jsobjinlines.h:1499
#2  newObjectFromHit (entry_=2, cx=<optimized out>, this=0x7ffff7e53e48) at ../jscntxtinlines.h:111
#3  js::NewObjectWithType (cx=<optimized out>, type=0x7ffff671d850, parent=(JSObject *) 0x7ffff6720060 [object global] delegate, kind=js::gc::FINALIZE_OBJECT4_BACKGROUND)
    at /srv/repos/mozilla-central/js/src/jsobj.cpp:1307
#4  0x00000000004c0509 in CreateThisForFunctionWithType (parent=<optimized out>, type=0x7ffff671d850, cx=0xadd640) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1415
#5  js_CreateThisForFunctionWithProto (cx=0xadd640, callee=(JSObject * const) 0x7ffff672dec0 [object Function "TestCase"], proto=<optimized out>) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1427
#6  0x00000000004c08cf in js_CreateThisForFunction (cx=0xadd640, callee=(JSObject * const) 0x7ffff672dec0 [object Function "TestCase"], newType=false) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1452
#7  0x000000000069833d in js::ion::CanEnter (cx=0xadd640, script=0x7ffff6724310, fp=0x7ffff69941e8, newType=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1461
#8  0x0000000000497e6c in js::Interpret (cx=0xadd640, entryFrame=0x7ffff6994150, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2411
#9  0x000000000049dbfb in js::RunScript (cx=0xadd640, script=0x7ffff6736480, fp=0x7ffff6994150) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:348
#10 0x000000000049de55 in js::ExecuteKernel (cx=0xadd640, script=0x7ffff6736480, scopeChain=..., thisv=..., type=<optimized out>, evalInFrame=..., result=0x7ffff6994128)
    at /srv/repos/mozilla-central/js/src/jsinterp.cpp:537
#11 0x00000000005dd5be in EvalKernel (cx=<optimized out>, args=..., evalType=<optimized out>, caller=..., scopeobj=(JSObject * const) 0x7ffff673ba00 [object Call] delegate)
    at /srv/repos/mozilla-central/js/src/builtin/Eval.cpp:286
#12 0x00000000005de6cd in js::DirectEval (cx=0xadd640, args=...) at /srv/repos/mozilla-central/js/src/builtin/Eval.cpp:337
#13 0x000000000049816c in js::Interpret (cx=0xadd640, entryFrame=0x7ffff69940b8, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2334
#14 0x000000000049dbfb in js::RunScript (cx=0xadd640, script=0x7ffff6736310, fp=0x7ffff69940b8) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:348
#15 0x000000000049e1ed in js::InvokeKernel (cx=0xadd640, args=..., construct=js::NO_CONSTRUCT) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:406
#16 0x000000000049e812 in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0xadd640) at /srv/repos/mozilla-central/js/src/jsinterp.h:131
#17 js::Invoke (cx=0xadd640, thisv=..., fval=..., argc=1, argv=<optimized out>, rval=0x7fffffffce98) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:439
#18 0x000000000071e4e6 in js::ion::InvokeFunction (cx=0xadd640, fun0=..., argc=1, argv=0x7fffffffced8, rval=0x7fffffffce98) at /srv/repos/mozilla-central/js/src/ion/VMFunctions.cpp:108
#19 0x00007ffff7e1ee7e in ?? ()
#20 0x0000000000000000 in ?? ()


The crash is due to out-of-memory, and the test is still quite complex, so I was hoping it can be resolved without the test. I took a backtrace from where OOM is reported before the crash:

Breakpoint 1, js_ReportOutOfMemory (cx=0xadd640) at /srv/repos/mozilla-central/js/src/jscntxt.cpp:511
511     {
(gdb) bt
#0  js_ReportOutOfMemory (cx=0xadd640) at /srv/repos/mozilla-central/js/src/jscntxt.cpp:511
#1  0x0000000000474ba7 in js::gc::ArenaLists::refillFreeList (cx=<optimized out>, thingKind=<optimized out>) at /srv/repos/mozilla-central/js/src/jsgc.cpp:1504
#2  0x00000000004b00d0 in NewGCThing<JSObject> (kind=js::gc::FINALIZE_OBJECT16_BACKGROUND, cx=0xadd640, thingSize=<optimized out>) at ../jsgcinlines.h:505
#3  js_NewGCObject (kind=js::gc::FINALIZE_OBJECT16_BACKGROUND, cx=0xadd640) at ../jsgcinlines.h:584
#4  create (slots=<optimized out>, type=0x7ffff671d0a0, shape=<optimized out>, kind=js::gc::FINALIZE_OBJECT16_BACKGROUND, cx=0xadd640) at /srv/repos/mozilla-central/js/src/jsobjinlines.h:972
#5  NewObject (cx=0xadd640, clasp=0xa978a0, type_=0x7ffff671d0a0, parent=<optimized out>, kind=js::gc::FINALIZE_OBJECT16_BACKGROUND) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1174
#6  0x00000000004bab8a in NewObjectWithClassProto (kind=js::gc::FINALIZE_OBJECT16_BACKGROUND, parent_=<optimized out>, proto_=0x0, clasp=0xa978a0, cx=0xadd640) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1282
#7  js::NewObjectWithClassProto (cx=0xadd640, clasp=0xa978a0, proto_=<optimized out>, parent_=<optimized out>, kind=<optimized out>) at /srv/repos/mozilla-central/js/src/jsobj.cpp:1238
#8  0x000000000048a0d7 in NewBuiltinClassInstance (kind=js::gc::FINALIZE_OBJECT16, clasp=<optimized out>, cx=0xadd640) at ../jsobjinlines.h:1598
#9  CheckNewScriptProperties (cx=0xadd640, type=0x7ffff671d850, fun=...) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:5132
#10 0x000000000048a59b in js::types::HeapTypeSet::isOwnProperty (this=0xb46e08, cx=0xadd640, object=<optimized out>, configurable=true) at /srv/repos/mozilla-central/js/src/jsinfer.cpp:1897
#11 0x00000000006b5535 in GetDefiniteSlot (atom=<optimized out>, types=0xb29568, cx=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/IonBuilder.cpp:5781
#12 js::ion::IonBuilder::jsop_setprop (this=0xaf1e98, name="type") at /srv/repos/mozilla-central/js/src/ion/IonBuilder.cpp:6476
#13 0x00000000006bb172 in js::ion::IonBuilder::inspectOpcode (this=0xaf1e98, op=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/IonBuilder.cpp:1051
#14 0x00000000006b9321 in js::ion::IonBuilder::traverseBytecode (this=0xaf1e98) at /srv/repos/mozilla-central/js/src/ion/IonBuilder.cpp:688
#15 0x00000000006bbedc in js::ion::IonBuilder::build (this=0xaf1e98) at /srv/repos/mozilla-central/js/src/ion/IonBuilder.cpp:341
#16 0x0000000000696d21 in js::ion::SequentialCompileContext::compile (this=<optimized out>, builder=<optimized out>, graph=<optimized out>, autoDelete=...) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1190
#17 0x000000000069770d in js::ion::IonCompile<js::ion::SequentialCompileContext> (cx=0xadd640, script=..., fun=(JSFunction * const) 0xae4a40 Cannot access memory at address 0x1501800000000, osrPc=0xaebde0 "", 
    constructing=true, compileContext=...) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1151
#18 0x0000000000697b83 in js::ion::Compile (cx=<optimized out>, script=0x7ffff6724310, fun=..., osrPc=<optimized out>, constructing=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1383
#19 0x0000000000698299 in js::ion::CanEnter (cx=0xadd640, script=0x7ffff6724310, fp=0x7ffff69941e8, newType=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1475
#20 0x0000000000497e6c in js::Interpret (cx=0xadd640, entryFrame=0x7ffff6994150, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2411
#21 0x000000000049dbfb in js::RunScript (cx=0xadd640, script=0x7ffff6736480, fp=0x7ffff6994150) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:348
#22 0x000000000049de55 in js::ExecuteKernel (cx=0xadd640, script=0x7ffff6736480, scopeChain=..., thisv=..., type=<optimized out>, evalInFrame=..., result=0x7ffff6994128)
    at /srv/repos/mozilla-central/js/src/jsinterp.cpp:537
#23 0x00000000005dd5be in EvalKernel (cx=<optimized out>, args=..., evalType=<optimized out>, caller=..., scopeobj=(JSObject * const) 0x7ffff673ba00 [object Call] delegate)
    at /srv/repos/mozilla-central/js/src/builtin/Eval.cpp:286
#24 0x00000000005de6cd in js::DirectEval (cx=0xadd640, args=...) at /srv/repos/mozilla-central/js/src/builtin/Eval.cpp:337
#25 0x000000000049816c in js::Interpret (cx=0xadd640, entryFrame=0x7ffff69940b8, interpMode=js::JSINTERP_NORMAL) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:2334
#26 0x000000000049dbfb in js::RunScript (cx=0xadd640, script=0x7ffff6736310, fp=0x7ffff69940b8) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:348
#27 0x000000000049e1ed in js::InvokeKernel (cx=0xadd640, args=..., construct=js::NO_CONSTRUCT) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:406
#28 0x000000000049e812 in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0xadd640) at /srv/repos/mozilla-central/js/src/jsinterp.h:131
#29 js::Invoke (cx=0xadd640, thisv=..., fval=..., argc=1, argv=<optimized out>, rval=0x7fffffffce98) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:439
#30 0x000000000071e4e6 in js::ion::InvokeFunction (cx=0xadd640, fun0=..., argc=1, argv=0x7fffffffced8, rval=0x7fffffffce98) at /srv/repos/mozilla-central/js/src/ion/VMFunctions.cpp:108
#31 0x00007ffff7e1ee7e in ?? ()
#32 0x0000000000000000 in ?? ()


Now checking this trace, frame #10 does a call that is infallible:

> CheckNewScriptProperties(cx, typeObj, fun);

in js/src/jsinfer.cpp around line 1897. Not sure if this is the reason/cause for the problem. Maybe someone with more experience in that code can check. Marking s-s because the crash doesn't look safe.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Is the test case reproducible?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Marking testcase-wanted.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Hanging a needinfo on Christian for comment 1 feedback. (Thanks)

Comment 4

[Christian Holler (:decoder)]

Attachment: Test case for shell

The original test was too large, but I isolated a very similar crash which has a shorter test and it's most likely the same bug. This test works for 64 bit debug builds with mozilla-central revision 0acbd06d48a9 and option --ion-eager.

The trace is this:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000a6de83 in CheckMarkedThing<js::Shape> (trc=0x7ffffffe56b0, thing=0x7ffff67411f0) at js/src/gc/Marking.cpp:114
114         JS_ASSERT(thing->zone()->rt == trc->runtime);
(gdb) bt
#0  0x0000000000a6de83 in CheckMarkedThing<js::Shape> (trc=0x7ffffffe56b0, thing=0x7ffff67411f0) at js/src/gc/Marking.cpp:114
#1  0x0000000000a69c02 in MarkInternal<js::Shape> (trc=0x7ffffffe56b0, thingp=0x7ffff672b080) at js/src/gc/Marking.cpp:163
#2  0x0000000000a65223 in js::gc::Mark<js::Shape> (trc=0x7ffffffe56b0, thing=0x7ffff672b080, name=0xf075ad "shape") at js/src/gc/Marking.cpp:204
#3  0x0000000000a50ccf in js::gc::MarkShape (trc=0x7ffffffe56b0, thing=0x7ffff672b080, name=0xf075ad "shape") at js/src/gc/Marking.cpp:335
#4  0x000000000090eb7b in js::ObjectImpl::markChildren (this=0x7ffff672b080, trc=0x7ffffffe56b0) at js/src/vm/ObjectImpl.cpp:307
#5  0x0000000000a5aac1 in js::gc::MarkChildren (trc=0x7ffffffe56b0, obj=(JSObject *) 0x7ffff672b080 [object Object] delegate) at js/src/gc/Marking.cpp:944
#6  0x0000000000a5e0f6 in js::TraceChildren (trc=0x7ffffffe56b0, thing=0x7ffff672b080, kind=JSTRACE_OBJECT) at js/src/gc/Marking.cpp:1455
#7  0x0000000000478564 in JS_TraceChildren (trc=0x7ffffffe56b0, thing=0x7ffff672b080, kind=JSTRACE_OBJECT) at js/src/jsapi.cpp:2458
#8  0x00000000005ba12e in CheckForCompartmentMismatches (rt=0x7ffff7e2b010) at js/src/jsgc.cpp:2662
#9  0x00000000005ba1c0 in BeginMarkPhase (rt=0x7ffff7e2b010) at js/src/jsgc.cpp:2675
#10 0x00000000005c3182 in IncrementalCollectSlice (rt=0x7ffff7e2b010, budget=0, reason=JS::gcreason::LAST_DITCH, gckind=js::GC_NORMAL) at js/src/jsgc.cpp:4184
#11 0x00000000005c399c in GCCycle (rt=0x7ffff7e2b010, incremental=false, budget=0, gckind=js::GC_NORMAL, reason=JS::gcreason::LAST_DITCH) at js/src/jsgc.cpp:4369
#12 0x00000000005c3f32 in Collect (rt=0x7ffff7e2b010, incremental=false, budget=0, gckind=js::GC_NORMAL, reason=JS::gcreason::LAST_DITCH) at js/src/jsgc.cpp:4494
#13 0x00000000005c40fc in js::GC (rt=0x7ffff7e2b010, gckind=js::GC_NORMAL, reason=JS::gcreason::LAST_DITCH) at js/src/jsgc.cpp:4517
#14 0x00000000005b566f in RunLastDitchGC (cx=0x13bae90, zone=0x142bc40, thingKind=js::gc::FINALIZE_OBJECT4_BACKGROUND) at js/src/jsgc.cpp:1497
#15 0x00000000005c78c5 in js::gc::ArenaLists::refillFreeList<(js::AllowGC)1> (cx=0x13bae90, thingKind=js::gc::FINALIZE_OBJECT4_BACKGROUND) at js/src/jsgc.cpp:1526
#16 0x00000000004d07c4 in js::gc::NewGCThing<JSObject, (js::AllowGC)1> (cx=0x13bae90, kind=js::gc::FINALIZE_OBJECT4_BACKGROUND, thingSize=64, heap=js::gc::DefaultHeap) at ../jsgcinlines.h:515
#17 0x00000000004c9a1d in js_NewGCObject<(js::AllowGC)1> (cx=0x13bae90, kind=js::gc::FINALIZE_OBJECT4_BACKGROUND, heap=js::gc::DefaultHeap) at ../jsgcinlines.h:570
#18 0x000000000067493a in JSObject::create (cx=0x13bae90, kind=js::gc::FINALIZE_OBJECT4_BACKGROUND, heap=js::gc::DefaultHeap, shape=0x7ffff6728c68, type=0x7ffff6726b30, slots=0x0) at ../jsobjinlines.h:949
#19 0x00000000006be479 in NewObject (cx=0x13bae90, clasp=0x135f1e0, type_=0x7ffff6726b30, parent=(JSObject *) 0x7ffff6729060 [object global] delegate, kind=js::gc::FINALIZE_OBJECT4_BACKGROUND, newKind=
    js::GenericObject) at js/src/jsobj.cpp:1202
#20 0x00000000006bf045 in js::NewObjectWithType (cx=0x13bae90, type=0x7ffff6726b30, parent=(JSObject *) 0x7ffff6729060 [object global] delegate, allocKind=js::gc::FINALIZE_OBJECT4_BACKGROUND, newKind=
    js::GenericObject) at js/src/jsobj.cpp:1350
#21 0x00000000006bfbca in CreateThisForFunctionWithType (cx=0x13bae90, type=0x7ffff6726b30, parent=(JSObject *) 0x7ffff6729060 [object global] delegate, newKind=js::GenericObject)
    at js/src/jsobj.cpp:1456
#22 0x00000000006bfcd8 in js::CreateThisForFunctionWithProto (cx=0x13bae90, callee=(JSObject * const) 0x7ffff6737fc0 [object Function "TestCase"], proto=(JSObject *) 0x7ffff672b080 [object Object] delegate, newKind=
    js::GenericObject) at js/src/jsobj.cpp:1469
#23 0x00000000006bff4f in js::CreateThisForFunction (cx=0x13bae90, callee=(JSObject * const) 0x7ffff6737fc0 [object Function "TestCase"], newType=false) at js/src/jsobj.cpp:1495
#24 0x0000000000bebb03 in js::ion::CanEnter (cx=0x13bae90, script=0x7ffff672d1f0, fp=..., isConstructing=true, newType=false) at js/src/ion/Ion.cpp:1487
[...]
(gdb) x /i $pc
=> 0xa6de83 <CheckMarkedThing<js::Shape>(JSTracer*, js::Shape*)+443>:   mov    0x20(%rax),%rdx
(gdb) info reg rax
rax            0xfffafffff6823940       -1407375042791104

Comment 5

[Andrew McCreight [:mccr8]]

Bill, could you take a look at this?  The crash in the second test case is in CheckForCompartmentMismatches, and the runtime of the marker isn't the same as the current zone, which seems bad.  We've had something like that before, but I don't remember what the outcome was there, if any.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This looks like an IonMonkey bug. The assertion mentioned above isn't failing, it's crashing during evaluation. We're trying to mark a shape whose ArenaHeader has been overwritten with garbage. I set a watchpoint to see why it's overwritten, and it triggers inside Ion code. It looks like Ion is trying to write a value there.

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

Hrm, am I missing something here? I get a mostly-bogus assert:

Program received signal SIGSEGV, Segmentation fault.
0x00000000009407a1 in toObject (this=0x7ffff637f1c0) at ./dist/include/js/Value.h:1111
1111	        MOZ_ASSERT(isObject());
(gdb) up
#1  js::StackFrame::constructorThis (this=0x7ffff637f1e8) at ../vm/Stack.h:810
810	        return formals()[-1].toObject();

We are OOMing while allocating |this| in a constructor, but the frame cleanup code still tries to take |this| as a return value, but it's undefined instead of an object since it was never allocated. The return value can't be read since it's an uncatchable exception.

Unless I'm seeing a completely different bug, this would be in the interpreter.

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

Okay, I get the right crash on the old cset now.

Comment 9

[David Anderson [:dvander] - inactive, e-mail if emergency]

To continue where Bill left off, it looks like we're overwriting the arena header in an MStoreFixedSlotT node. I think the node is generated for line 7 in the test case.

7:      this.reason = '';
8:      this.bugnumber = typeof(BUGNUMER) != 'undefined' ? BUGNUMBER : '';

Here's what's happening in C++. We're in IonBuilder::jsop_setprop() for line #8, and we call GetDefiniteSlot(), which works its way into TI. Then we OOM on this NewObject call in jsinfer.cpp:

    /* Strawman object to add properties to and watch for duplicates. */
    state.baseobj = NewBuiltinClassInstance(cx, &ObjectClass, gc::FINALIZE_OBJECT16);
    if (!state.baseobj) {
        if (type->newScript)
            type->clearNewScript(cx);

The clearNewScript() happens, and we end up using an MSetPropertyCache.

Brian, could there be something going wrong in that, we generate a definite property store, but then the TypeNewScript gets invalidated during compilation, and we don't account for that?

Comment 10

[Brian Hackett [Laid off!]]

Attachment: patch

This should fix the crash.  TI functions are generally infallible because they are supposed to nuke type info and disable TI should any allocations or operations actually fail.  This looks like it happens in all the right places under CheckNewScriptProperties except after this NewBuiltinClassInstance call.

It's somewhat curious that the new script properties weren't analyzed until the middle of compilation, they normally get analyzed the first time the compiler asks for them which I would expect to happen at the earlier writes.  Anyhow, what's presumably happening is that the earlier MStoreFixedSlot assumes an object with a larger size class (as indicated by the newScript info), and after the newScript is cleared but compilation is not aborted then the 'this' object is allocated with a smaller, default size class and the write spills over into the next arena's header.

Comment 11

[Christian Holler (:decoder)]

Comment on attachment 718970 [details] [diff] [review]
patch

With the patch applied, the opt-crash is gone and the debug build now gives me:

Assertion failure: isObject(), at ./dist/include/js/Value.h:1111

which is the other bug that dvander was probably seeing. Feedback+ based on that.

Comment 12

[David Anderson [:dvander] - inactive, e-mail if emergency]

Comment on attachment 718970 [details] [diff] [review]
patch

Thanks!

Comment 13

[Brian Hackett [Laid off!]]

Comment on attachment 718970 [details] [diff] [review]
patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

not at all.  this requires an OOM to happen at a precise point during compilation.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

no

Which older supported branches are affected by this flaw?

all of them

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

no testing needed

Comment 14

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

Comment on attachment 718970 [details] [diff] [review]
patch

I'm going to assume that we want this on Aurora and Beta as a sec-high. Release management to confirm.

Comment 15

[Alex Keybl [:akeybl]]

Assuming this is low risk, please request approval for all branches.

Comment 16

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/533ec27c9c33

Comment 17

[Alex Keybl [:akeybl]]

(In reply to Brian Hackett (:bhackett) from comment #16)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/533ec27c9c33

Please nominate for uplift to Aurora/Beta asap - we're going to build with the fourth week's beta Tuesday.

Comment 18

[Alex Keybl [:akeybl]]

Whoops, this already has approval from 5 days ago. Including Ryan to land, in case Brian isn't available for some reason.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Helps when bugs are resolved after they land on m-c.
https://hg.mozilla.org/mozilla-central/rev/533ec27c9c33

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b3b1cbcc2498
https://hg.mozilla.org/releases/mozilla-beta/rev/5c62ad643a61
https://hg.mozilla.org/releases/mozilla-esr17/rev/c9463a1fa915

Comment 21

[Matt Wobensmith [:mwobensmith][:matt:]]

Christian - will this test make its way into a test suite? Does it require manual verification? Or have you already verified it to be fixed? Comment 11 sounds like there might be an outstanding issue.

Thanks.

Comment 22

[Alex Keybl [:akeybl]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/b3b1cbcc2498
> https://hg.mozilla.org/releases/mozilla-beta/rev/5c62ad643a61
> https://hg.mozilla.org/releases/mozilla-esr17/rev/c9463a1fa915

Would you mind also landing to mozilla-b2g18?

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/cb384b51d0ba