Note: There are a few cases of duplicates in user autocompletion which are being worked on.

crash access violation mozjs!js::types::AutoEnterCompilation::~AutoEnterCompilation

RESOLVED FIXED in Firefox 19

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: wsmwk, Assigned: nbp)

Tracking

({crash, regression, sec-critical})

17 Branch
mozilla20
All
Windows 7
crash, regression, sec-critical
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, firefox17 wontfix, firefox18- wontfix, firefox19+ fixed, firefox20+ fixed, firefox-esr10 unaffected, firefox-esr1719+ fixed, b2g1819+ fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

(Whiteboard: [has stacktrace][qa-][adv-main19+][adv-esr1703+], crash signature)

Attachments

(5 attachments, 1 obsolete attachment)

Created attachment 649172 [details]
windbg stacktrace

+++ This bug was initially created as a clone of Bug #743221 +++

perhaps related to bug 743221 - unclear as yet. captured by windbg. Having trouble recalling steps at the moment.


(74e0.d44): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=2238525c ebx=2866c000 ecx=22385000 edx=0749df00 esi=7eb00000 edi=002c8370
eip=678d1eaa esp=002c8358 ebp=002c8378 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
*** WARNING: Unable to verify checksum for C:\Program Files\Mozilla.org\FF 17.0a1 2012-08-02\mozjs.dll
mozjs!js::types::AutoEnterCompilation::~AutoEnterCompilation+0x1a:
678d1eaa 8b0e            mov     ecx,dword ptr [esi]  ds:0023:7eb00000=????????
0:000> ~* kp;!analyze -f;lm

.  0  Id: 74e0.d44 Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr  
002c835c 678ebf04 mozjs!js::types::AutoEnterCompilation::~AutoEnterCompilation(void)+0x1a [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\jsinferinlines.h @ 286]
002c8378 678ec0fa mozjs!js::mjit::Compiler::performCompilation(void)+0x94 [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\methodjit\compiler.cpp @ 510]
002c8388 678ec45f mozjs!js::mjit::Compiler::compile(void)+0xa [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\methodjit\compiler.cpp @ 112]
002cc4a0 67848f99 mozjs!js::mjit::CanMethodJIT(struct JSContext * cx = 0x146a3de0, struct JSScript * script = 0x2866c028, unsigned char * pc = 0x17d25c44 ">W", bool construct = false, js::mjit::CompileRequest request = CompileRequest_Interpreter (0n0), class js::StackFrame * frame = 0x04de01b0)+0x2af [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\methodjit\compiler.cpp @ 998]
002ccd9c 67851d70 mozjs!js::Interpret(struct JSContext * cx = 0x146a3de0, class js::StackFrame * entryFrame = 0x04de0068, js::InterpMode interpMode = JSINTERP_NORMAL (0n0))+0xf49 [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\jsinterp.cpp @ 2446]
002cce10 678523fa mozjs!js::InvokeKernel(struct JSContext * cx = 0x146a3de0, class JS::CallArgs args = class JS::CallArgs, js::MaybeConstruct construct = NO_CONSTRUCT (0n0))+0x610 [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\jsinterp.cpp @ 356]
002cce58 67872ea1 mozjs!js::Invoke(struct JSContext * cx = 0x146a3de0, class JS::Value * thisv = 0x002cce80, class JS::Value * fval = 0x002cce9c, unsigned int argc = 0, class JS::Value * argv = 0x00000000, class JS::Value * rval = 0x002ccee0)+0x1ba [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\jsinterp.cpp @ 388]
*** WARNING: Unable to verify checksum for C:\Program Files\Mozilla.org\FF 17.0a1 2012-08-02\xul.dll
002cce8c 59a6035a mozjs!JS_CallFunctionValue(struct JSContext * cx = 0x146a3de0, struct JSObject * objArg = 0x1fb55040, class JS::Value fval = class JS::Value, unsigned int argc = 0, class JS::Value * argv = 0x00000000, class JS::Value * rval = 0x002ccee0)+0x41 [e:\builds\moz2_slave\m-cen-w32-ntly\build\js\src\jsapi.cpp @ 5836]
002cd030 59a31f3b xul!nsJSContext::CallEventHandler(class nsISupports * aTarget = 0x1c08cc40, struct JSObject * aScope = 0x1fb55040, struct JSObject * aHandler = 0x286a6960, class nsIArray * aargv = 0x1859b9e0, class nsIVariant ** arv = 0x002cd080)+0x47a [e:\builds\moz2_slave\m-cen-w32-ntly\build\dom\base\nsjsenvironment.cpp @ 1929]
002cd08c 59a3a428 xul!nsGlobalWindow::RunTimeoutHandler(struct nsTimeout * aTimeout = 0x2238525c, class nsIScriptContext * aScx = 0x1747c8d0)+0xeb [e:\builds\moz2_slave\m-cen-w32-ntly\build\dom\base\nsglobalwindow.cpp @ 9555]
002cd118 59b7bacc xul!nsGlobalWindow::RunTimeout(struct nsTimeout * aTimeout = 0x185d1ce0)+0x1e8 [e:\builds\moz2_slave\m-cen-w32-ntly\build\dom\base\nsglobalwindow.cpp @ 9806]
002cd130 59a73a54 xul!nsGlobalWindow::TimerCallback(class nsITimer * aTimer = 0x185d26d0, void * aClosure = 0x185d1ce0)+0x1b [e:\builds\moz2_slave\m-cen-w32-ntly\build\dom\base\nsglobalwindow.cpp @ 10072]
002cd160 59aa6960 xul!nsTimerImpl::Fire(void)+0xf4 [e:\builds\moz2_slave\m-cen-w32-ntly\build\xpcom\threads\nstimerimpl.cpp @ 473]
002cd1d0 59a6e6d9 xul!nsThread::ProcessNextEvent(bool mayWait = false, bool * resu

Comment 1

5 years ago
It first appeared in 17.0a1/20120719, but it has been discontinuous across builds.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AAutoEnterCompilation%3A%3A~AutoEnterCompilation%28%29
Crash Signature: [@ EMPTY: no crashing thread identified; corrupt dump ] → [@ EMPTY: no crashing thread identified; corrupt dump ] [@ js::types::AutoEnterCompilation::~AutoEnterCompilation()]
Keywords: regression
OS: All → Windows 7
Version: Trunk → 17 Branch
(to clarify)
I left [@ EMPTY: no crashing thread identified; corrupt dump ] in crash sigs because if I were not running windbg, it eventually crashes with [@ EMPTY: no crashing thread identified; corrupt dump ]. Or at least, that's what all my crash reports have been - which are numerous (5-10 per month). The most recent:

bp-1bbf76a2-877c-40b0-82d7-26aba2120805 8/5/20129:07 AM
bp-c0319d4c-0ea2-4d84-a3ab-857082120805 8/5/20121:46 AM
bp-e09a0a9d-0d05-4bca-a1c2-e89ba2120805 8/4/201211:31 PM
bp-6778689c-3ef2-407e-b48a-8dd652120803 8/2/201211:36 PM
bp-4e2f767d-528b-4031-9ee3-e8bd62120803 8/2/20129:22 PM
bp-caad95ad-7013-4817-a9c6-e11f421208017/31/201210:22 PM
(Assignee)

Updated

5 years ago
Assignee: general → nicolas.b.pierron
Status: NEW → ASSIGNED
nbp, I'm OK to close if you think this should be gone with that bug fixed.
Blocks: 772509
Depends on: 780274
Summary: access violation mozjs!js::types::AutoEnterCompilation::~AutoEnterCompilation → crash access violation mozjs!js::types::AutoEnterCompilation::~AutoEnterCompilation
(Assignee)

Comment 5

5 years ago
(In reply to Wayne Mery (:wsmwk) from comment #4)
> nbp, I'm OK to close if you think this should be gone with that bug fixed.

This bug should be definitively fixed with Bug 777537 patch.

CC me if any identical failures including AutoEnterCompilation::~AutoEnterCompilation and/or CompilerOutput::isValid appear in a backtrace.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Target Milestone: --- → mozilla17

Updated

5 years ago
Target Milestone: mozilla17 → mozilla18

Updated

5 years ago
status-firefox17: --- → affected
Scoobidiver, if bug 777537 was fixed in FF17 (has TM=17) then why is this not also TM=17?

Comment 7

5 years ago
(In reply to Wayne Mery (:wsmwk) from comment #6)
> Scoobidiver, if bug 777537 was fixed in FF17 (has TM=17) then why is this
> not also TM=17?
I don't have access to bug 780274 to see if the patch landed in 17.0 or 18.0 but I can assure you there are still crashes in 17.0 Beta. See the link in comment 1.
(In reply to Scoobidiver from comment #7)
> (In reply to Wayne Mery (:wsmwk) from comment #6)
> > Scoobidiver, if bug 777537 was fixed in FF17 (has TM=17) then why is this
> > not also TM=17?
> I don't have access to bug 780274 to see if the patch landed in 17.0 or 18.0
> but I can assure you there are still crashes in 17.0 Beta. See the link in
> comment 1.

#73 crash for FF17. And occurs on current trunk.
for example bp-ed137fa9-cee8-482f-8c9d-d10582121225
Status: RESOLVED → REOPENED
Flags: needinfo?(nicolas.b.pierron)
Resolution: FIXED → ---
(Assignee)

Comment 9

5 years ago
(In reply to Wayne Mery (:wsmwk) from comment #8)
> (In reply to Scoobidiver from comment #7)
> > (In reply to Wayne Mery (:wsmwk) from comment #6)
> > > Scoobidiver, if bug 777537 was fixed in FF17 (has TM=17) then why is this
> > > not also TM=17?
> > I don't have access to bug 780274 to see if the patch landed in 17.0 or 18.0
> > but I can assure you there are still crashes in 17.0 Beta. See the link in
> > comment 1.
> 
> #73 crash for FF17. And occurs on current trunk.
> for example bp-ed137fa9-cee8-482f-8c9d-d10582121225

I looked again at this crash report, and it seems that we have 2 different kind of crashes, the previous one that you give the link to is a bad read access, while others recent one are bad write access to random memory (base + 0x0004) where base is not-NULL.  It looks like “base + 0x0004” is likely to be coming from the next line. (in fact it is …)

By reading the code, I remarked that a few cases to handle allocation issues might cause the init function to fail.  If the init function fails, we will still enter the destructor which need to check that we are definitely failing the compilation and that the compiler output registered by the init function is not available.

Mark this bug as s-s sec-critical because of random+0x0004 write.
Group: core-security
Status: REOPENED → ASSIGNED
Flags: needinfo?(nicolas.b.pierron)
Keywords: sec-critical
(Assignee)

Comment 10

5 years ago
Created attachment 695782 [details] [diff] [review]
Handle init function failures in the destructor.

Reset the outputIndex in case of failure and use it to check that we have a valid compilerOutput.
Attachment #695782 - Flags: review?(bhackett1024)
Attachment #695782 - Flags: review?(bhackett1024) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4a66a93f8625
Backed out in:

https://hg.mozilla.org/integration/mozilla-inbound/rev/9afe21048168

for causing mochitest failures.

See https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4a66a93f8625
(Assignee)

Comment 13

5 years ago
(In reply to Gary Kwong [:gkw] from comment #12)
> Backed out in:
> 
> https://hg.mozilla.org/integration/mozilla-inbound/rev/9afe21048168
> 
> for causing mochitest failures.
> 
> See https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=4a66a93f8625

The assertion added in this code seems to fail because threaded compilation is starting 2 compilations and the destructor is seems to be called later on.  I will investigate if there is any consequence to the current code, but threaded compilation has been enabled recently and this should not affect 17 / 18.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff367beb8 in js::types::AutoEnterCompilation::~AutoEnterCompilation (this=0x7fffffff4440, __in_chrg=<optimized out>)
    at /home/nicolas/mozilla/ionmonkey/js/src/jsinferinlines.h:469
469             JS_ASSERT(info.outputIndex + 1 == cx->compartment->types.constrainedOutputs->length());
(gdb) p cx->compartment->types.constrainedOutputs->length()
$1 = 14
(gdb) p info.outputIndex
$2 = 12
(gdb) bt
#0  0x00007ffff367beb8 in js::types::AutoEnterCompilation::~AutoEnterCompilation (this=0x7fffffff4440, __in_chrg=<optimized out>)
    at /home/nicolas/mozilla/ionmonkey/js/src/jsinferinlines.h:469
#1  0x00007ffff3742251 in js::ion::AttachFinishedCompilations (cx=0x7fffd67950c0)
    at /home/nicolas/mozilla/ionmonkey/js/src/ion/Ion.cpp:1106
#2  0x00007ffff3375868 in js_InvokeOperationCallback (cx=0x7fffd67950c0) at /home/nicolas/mozilla/ionmonkey/js/src/jscntxt.cpp:1066
#3  0x00007ffff33758d1 in js_HandleExecutionInterrupt (cx=0x7fffd67950c0) at /home/nicolas/mozilla/ionmonkey/js/src/jscntxt.cpp:1083
#4  0x00007ffff38b3a3f in js::mjit::stubs::Interrupt (f=..., pc=0x7fffd688d5ba ":")
    at /home/nicolas/mozilla/ionmonkey/js/src/methodjit/StubCalls.cpp:805
#5  0x00007fffe414efe7 in ?? ()
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/58d263c1c3dc

The threaded compilation does an init for each compilation which is spawned, and a second AutoEnterCompilation when it links the generated code.  This means that we can have multiple compilation queued in the AutoEnterCompilation.  So I changed the assert to make sure the the outputIndex is belowed the contrainedOutputs length.
(Assignee)

Updated

5 years ago
status-b2g18: --- → affected
status-firefox18: --- → affected
status-firefox19: --- → affected
status-firefox20: --- → fixed
status-firefox-esr17: --- → affected
tracking-b2g18: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
tracking-firefox20: --- → ?
tracking-firefox-esr17: --- → ?
Why was this not nominated for sec-approval before being checked in, since it affects branches?
https://hg.mozilla.org/mozilla-central/rev/58d263c1c3dc

Though I noticed, after merging to m-c of course (fail), that this may have caused fairly frequent OSX debug xpcshell crashes like the one in the log below. Retriggers are already pending. So there may be a backout coming.
https://tbpl.mozilla.org/php/getParsedLog.php?id=18301491&tree=Mozilla-Inbound
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: mozilla18 → mozilla20
(Assignee)

Comment 17

5 years ago
(In reply to Ryan VanderMeulen [Intermittent Availability Until Jan. 2] from comment #16)
> https://hg.mozilla.org/mozilla-central/rev/58d263c1c3dc
> 
> Though I noticed, after merging to m-c of course (fail), that this may have
> caused fairly frequent OSX debug xpcshell crashes like the one in the log
> below. Retriggers are already pending. So there may be a backout coming.
> https://tbpl.mozilla.org/php/getParsedLog.php?id=18301491&tree=Mozilla-
> Inbound

Looking at inbound history and annotation it seems that this was related to another changed backout at https://hg.mozilla.org/integration/mozilla-inbound/rev/f2a500997116 .

I am re-opening this bug, because I noticed that the returned value of the init function was not checked during Ion compilation, which means that we will write the -1 offset of the same pointer if there is an OOM, and segv/leak while garbage collecting the next time.  I'll submit the follow-up patch in a few seconds.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 18

5 years ago
Created attachment 696252 [details] [diff] [review]
Check returned value of AutoEnterCompilation::init in Ion compilation.

I added checks to make sure that we don't ignore the return value of init in AutoEnterCompilation, but it seems that it was first ignored in Ion compilation.

This means, with the previous patch, that in case of OOM we would have corrupted some allocated memory.

This patch does not show as part of the original issue, but as the previous patch for this issue check that we consider the returned value of the init function, I think it is worth going with this issue as the init function has been modified to reset the outputIndex.
Attachment #696252 - Flags: review?(bhackett1024)
Attachment #696252 - Flags: review?(bhackett1024) → review+
(Assignee)

Comment 19

5 years ago
Comment on attachment 696252 [details] [diff] [review]
Check returned value of AutoEnterCompilation::init in Ion compilation.

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

Need an OOM during the compilation. not trivial for me.

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 since 17, but with the previous patch, this exchange on random write (with crash) by a silent one.

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

This one, this patch should be merged with the previous one before being back-ported to all branches.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

Not yet.  Except a recent modification in Ion.cpp which is modified by this file, this should be easy to provide.

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

No regression expected for this patch.
Attachment #696252 - Flags: sec-approval?
(Assignee)

Comment 20

5 years ago
Created attachment 696422 [details] [diff] [review]
inbound patch [part 2, rebased]

This fix a compilation issue related to the change of the return value type made a few hours ago. (same logic as attachment 696252 [details] [diff] [review])
Attachment #696252 - Flags: sec-approval? → sec-approval+
(Assignee)

Comment 21

5 years ago
Created attachment 696426 [details] [diff] [review]
aurora patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 772509

User impact if declined: crash, https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AAutoEnterCompilation%3A%3A~AutoEnterCompilation%28%29

Testing completed (on m-c, etc.):
part 1, yes
part 2: to be landed after sec-approval.
(This patch merge both into one)

Risk to taking this patch (and alternatives if risky):
seems low. (JS test suite ok)

String or UUID changes made by this patch: N/A
Attachment #696426 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 22

5 years ago
Created attachment 696430 [details] [diff] [review]
beta patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 772509

User impact if declined: crash, https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AAutoEnterCompilation%3A%3A~AutoEnterCompilation%28%29

Testing completed (on m-c, etc.):
part 1, yes
part 2: to be landed after sec-approval.
(This patch merge both into one)

Risk to taking this patch (and alternatives if risky):
seems low.

String or UUID changes made by this patch: N/A
Attachment #696430 - Flags: approval-mozilla-beta?
(Assignee)

Comment 23

5 years ago
Comment on attachment 695782 [details] [diff] [review]
Handle init function failures in the destructor.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 772509

User impact if declined: crash, https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AAutoEnterCompilation%3A%3A~AutoEnterCompilation%28%29

Testing completed (on m-c, etc.):
part 1, yes
part 2: to be landed after sec-approval.
(This patch merge both into one)

Risk to taking this patch (and alternatives if risky):
seems low.

String or UUID changes made by this patch: N/A



[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
sec-critical, cause crashes by writing at random memory addresses. (#73)

User impact if declined: crash, https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AAutoEnterCompilation%3A%3A~AutoEnterCompilation%28%29

Fix Landed on Version: inbound & central, the part 2 is not needed as the second part of this bug deals with IonMonkey which landed in Fx 18 (beta).

Risk to taking this patch (and alternatives if risky): 
seems low.

String or UUID changes made by this patch: N/A

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #695782 - Flags: approval-mozilla-release?
Attachment #695782 - Flags: approval-mozilla-esr17?
(Assignee)

Comment 24

5 years ago
Comment on attachment 696430 [details] [diff] [review]
beta patch

[Approval Request Comment]
See comment #22 (same patch)
Attachment #696430 - Flags: approval-mozilla-b2g18?
(Assignee)

Comment 25

5 years ago
Comment on attachment 696422 [details] [diff] [review]
inbound patch [part 2, rebased]

Obsolete because bug 823884 as been backout at changeset e497c2e40dc6.
Use attachment 696252 [details] [diff] [review] instead.
Attachment #696422 - Attachment is obsolete: true
(Assignee)

Comment 26

5 years ago
Comment on attachment 696252 [details] [diff] [review]
Check returned value of AutoEnterCompilation::init in Ion compilation.

Use attachment 696422 [details] [diff] [review] if bug 823884 is re-landed before this patch.
Attachment #696252 - Flags: checkin?(ryanvm)
Keywords: checkin-needed
Attachment #696252 - Flags: checkin?(ryanvm)
(Assignee)

Comment 27

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8468d858595c (part 2)

This part of the patch should go in all version after fx 18, including fx 18. as it deals with IonMonkey missing check.
Keywords: checkin-needed

Comment 28

5 years ago
(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #27)
> This part of the patch should go in all version after fx 18, including fx
> 18. as it deals with IonMonkey missing check.

As 18 is closed for anything other than the last two high-value fixes we are tracking, you should probably email release-mgmt in addition to those approval requests if this really should still land there.
This does not seem to be a top-crasher in FF18 and we already have our scheduled final beta 6 out . We are spinning an urgent beta 7 only for blocker issues at this time for Fx18.Hence approving the patch only for aurora/b2g18 .

In addition I am not approving the patch for release, as we would not be chemspilling for this issue.
https://hg.mozilla.org/mozilla-central/rev/8468d858595c
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
tracking-firefox17: ? → ---
tracking-firefox18: ? → -
tracking-firefox19: --- → +
tracking-firefox20: ? → +

Updated

5 years ago
Attachment #695782 - Flags: approval-mozilla-release? → approval-mozilla-release-

Updated

5 years ago
Attachment #696426 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

5 years ago
Attachment #696430 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

Comment 31

5 years ago
Oh, and we check in a sec-crit fix more than a week before releasing a vulnerable version? That doesn't sound good to me. :(
(Assignee)

Comment 32

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/ffa57091f9fa
status-firefox19: affected → fixed

Updated

5 years ago
status-firefox-esr10: --- → unaffected
tracking-b2g18: ? → 19+
tracking-firefox-esr17: ? → 19+
(Assignee)

Comment 33

5 years ago
What is the meaning of 19+ for tracking flags?
Flags: needinfo?(akeybl)
I think it means the version of esr17 (or whatever) that will be released at the same time as Firefox 19.
(In reply to Andrew McCreight [:mccr8] from comment #34)
> I think it means the version of esr17 (or whatever) that will be released at
> the same time as Firefox 19.

Correct.
Flags: needinfo?(akeybl)
Do we have steps to reproduce this crash which QA can use for verification?
Keywords: steps-wanted
Whiteboard: [has stacktrace] → [has stacktrace][qa?]
(Assignee)

Comment 37

5 years ago
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #36)
> Do we have steps to reproduce this crash which QA can use for verification?

You need to be at the limit to the OOM, and have plenty of concurrent Ion compilations, then after this is a question of luck to hit this error.

One potential script which might trigger OOM in a similar area would be something like:

var nFun = 10000;
var triggerIon = 15000;
var funs = new Array(nFun);

for (var i = 0; i < nFun; i++)
  funs[i] = new Function("");

for (var j = 0; j < triggerIon; j++) {
  // Will cause plenty of Ion compilation in parallel.
  for (var f = 0; f < nFun; f++)
     funs[f]();
}

Sadly this would be hardly reproducible as you are more likely to have OOM for other reasons than in the AutoEnterCompilation.  If you want to attack such OOM cases, try to increase nFun to cause the grow (reallocation) of the compilerOutput vector during the append function contained in the init function.
Thanks Nicolas. Unfortunately, given the complexity to reproduce this crash, I don't think QA won't be able to reliably verify this is fixed in a timely manner. Marking this bug as [qa-].

Would this be something we could explore covering with automation?
Whiteboard: [has stacktrace][qa?] → [has stacktrace][qa-]
Leaving the approval nom until we are ready to take landings for v1-train on b2g18 branch as per https://wiki.mozilla.org/Release_Management/B2G_Landing

Updated

5 years ago
Attachment #695782 - Flags: approval-mozilla-esr17? → approval-mozilla-esr17+
Please go ahead and land this for esr17 at this time.
Keywords: checkin-needed
Landed on esr17 minus the Ion.cpp bits.
https://hg.mozilla.org/releases/mozilla-esr17/rev/54f5dba3caf4
status-firefox17: affected → wontfix
status-firefox18: affected → wontfix
status-firefox-esr17: affected → fixed
Keywords: checkin-needed
Attachment #696430 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
https://hg.mozilla.org/releases/mozilla-b2g18/rev/8cd47ef18c2f
status-b2g18: affected → fixed
Whiteboard: [has stacktrace][qa-] → [has stacktrace][qa-][adv-main19+][adv-esr1703+]

Updated

4 years ago
Keywords: steps-wanted
Since Firefox 20 is now released, v1.0.1 branches are still open, and this is considered low risk, we can uplift to v1.0.1. Marking as tef+ and flipping status-b2g18-v1.0.1 to affected.
blocking-b2g: --- → tef+
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
In before the branch.
status-b2g18-v1.0.1: affected → fixed
Group: core-security
You need to log in before you can comment on or make changes to this bug.