963290 - [B2G][Browser]Lots of leaked content parents

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[Ross Kuhlman ([e-mail])]

Attachment: quoraOOM.txt

The device will fail to load www.quora.com if there is limited available memory. After displaying a blank page for about a minute, the "Well, this is embarassing!" page will be displayed. This issue appears to be memory elated because it does not occur on freshly restarted devices.

Repro Steps:
*Prerequisite: Device has been on and in use for a significant period of time.

1) Updated Buri to BuildID: 20140122004001
2) Launch Browser app.
3) Navigate to 'www.quora.com'.

Actual:
After a lengthy loading period, the browser displays the "Well, this is embarassing!" page.

Expected:
Page loads successfully.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20140121004137
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Gecko: 6f7dfe36ab6c
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:
Issue does not occur on recently restarted devices.

Repro frequency: 80%
See attached: logcat

Comment 1

[Jason Smith [:jsmith]]

Does this happen on 1.2 or 1.1?

Comment 2

[Ross Kuhlman ([e-mail])]

Issue also occurs in 1.2
Environmental Variables:
Device: Buri v1.2 Moz RIL
BuildID: 20140114004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: 42a1c35fc831
Version: 26.0
Firmware Version: v1.2-device.cfg

Currently unable to test in 1.1 due to shortage of devices and excessive time requirement to reproduce. I will report on this later today

Comment 3

[Sarah Parsons]

Unable to repro on Buri 1.1 Build ID: 20140123041201

Gaia   c434fe9a0e823029796805e141cfa983cda2d246
SourceStamp aa0ceb07a73e
BuildID 20140123041201
Version 18.0

Comment 4

[Jason Smith [:jsmith]]

Does this reproduce on the earliest 1.2 build available?

Comment 5

[Sarah Parsons]

Checked on the first Buri 1.2 BuildID 20130621031231 both Ross and I were unable to reproduce the issue.

Gaia   e2f19420fa6a26c4287588701efaec09a750dba1
SourceStamp 7ba8c86f1a56
BuildID 20130621031231
Version 24.0a1

Comment 6

[Jason Smith [:jsmith]]

So I tried reproducing this, but couldn't get this to reproduce after a couple of tries. Is the reproduction rate right here? Can someone double check the reproduction rate?

Comment 7

[Ross Kuhlman ([e-mail])]

Nailing down a reproduction rate is difficult. I have been able to reproduce this issue on multiple devices with 100% reproducibility, but as soon as the device has been restarted, quora.com loads successfully. The device must be on and seeing general use for a significant amount of time.
After a device has been on and seen moderate to heavy use for several hours, this issue is very easy to reproduce. Once it occurs on a device, it will continue to occur on that device with 100% reproducibility until the device gets restarted. I have not been able to force the issue by utilizing numerous memory intensive apps.

Comment 8

[Jason Smith [:jsmith]]

Top Site Ranking - http://www.alexa.com/siteinfo/quora.com

* Global - 434
* India - 87

Comment 9

[Jason Smith [:jsmith]]

The site is high enough on alexa that we probably need to care about this working correctly. The typical use case for phones is long running usage, not short running usage. So based on comment 7, I actually think that there's a high chance a user will hit this if he/she tries to use Quora.

QA Wanted to get an about memory report when this bug reproduces. See https://bugzilla.mozilla.org/show_bug.cgi?id=958230#c24 for steps to do this.

Comment 10

[sarsenyev]

Attachment: about-memory.zip

please see about memory report attached.

Comment 11

[Jason Smith [:jsmith]]

The reproduction rate turns out to be low to initially reproduce it, but once it reproduces, it will reproduce consistently until you restart your phone. Given that the initial reproduction rate is low & there's a workaround, I'm going unnom this.

Comment 12

[Nicholas Nethercote [inactive]]

From about:memory:

Main Process (pid 136)
Explicit Allocations
74.96 MB (100.0%) -- explicit
├──32.03 MB (42.73%) ── heap-unclassified

That's bad. As is this:

0 (100.0%) -- queued-ipc-messages
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x43544c00, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x43548000, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x435cac00, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x44151400, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x4485d800, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x45035000, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x45283800, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x45caa000, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x47b2b800, refcnt=1)
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x47bba400, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x44782400, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x4485e000, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x4501ec00, refcnt=2)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x45038800, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x45281800, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x45ce2800, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=-1, closed channel, 0x46179400, refcnt=1)
├──0 (100.0%) ── content-parent(Browser, pid=4050, open channel, 0x4414b000, refcnt=17)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x44859c00, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x4547e000, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x45482800, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x45565c00, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x461d2800, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x461d6c00, refcnt=1)
├──0 (100.0%) ── content-parent(Calendar, pid=-1, closed channel, 0x46d46000, refcnt=1)
├──0 (100.0%) ── content-parent(Communications, pid=-1, closed channel, 0x4485f000, refcnt=1)
├──0 (100.0%) ── content-parent(Communications, pid=-1, closed channel, 0x458ec000, refcnt=1)
├──0 (100.0%) ── content-parent(E-Mail, pid=-1, closed channel, 0x4542ac00, refcnt=1)
├──0 (100.0%) ── content-parent(E-Mail, pid=-1, closed channel, 0x45561400, refcnt=1)
├──0 (100.0%) ── content-parent(E-Mail, pid=-1, closed channel, 0x46d6bc00, refcnt=1)
├──0 (100.0%) ── content-parent(Gallery, pid=-1, closed channel, 0x435c8000, refcnt=1)
├──0 (100.0%) ── content-parent(Gallery, pid=-1, closed channel, 0x461d5000, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x4527d800, refcnt=2)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45c81000, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x461acc00, refcnt=1)
├──0 (100.0%) ── content-parent(Marketplace, pid=-1, closed channel, 0x4354ac00, refcnt=1)
├──0 (100.0%) ── content-parent(Marketplace, pid=-1, closed channel, 0x44858400, refcnt=1)
├──0 (100.0%) ── content-parent(Marketplace, pid=-1, closed channel, 0x4527dc00, refcnt=1)
├──0 (100.0%) ── content-parent(Messages, pid=-1, closed channel, 0x45483800, refcnt=1)
├──0 (100.0%) ── content-parent(Settings, pid=-1, closed channel, 0x43549400, refcnt=1)
├──0 (100.0%) ── content-parent(Settings, pid=-1, closed channel, 0x444a0000, refcnt=1)
├──0 (100.0%) ── content-parent(Tuenti, pid=-1, closed channel, 0x44788400, refcnt=2)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x43549000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x43ce0000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x4485ac00, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x4485b800, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x4485c000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x448c7000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x45034000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x45036000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x45426c00, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x4547f400, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x45563c00, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x46d44800, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x46d44c00, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x47074000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x471f3800, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x47b2b000, refcnt=1)
├──0 (100.0%) ── content-parent(Usage, pid=-1, closed channel, 0x47bb9400, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x44783800, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x44784400, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x44784c00, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x44785400, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x45283000, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x4547d400, refcnt=2)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x45480c00, refcnt=1)
├──0 (100.0%) ── content-parent(Vivo Chat, pid=-1, closed channel, 0x45cc6400, refcnt=1)
├──0 (100.0%) ── content-parent(YouTube, pid=-1, closed channel, 0x4485e800, refcnt=1)
├──0 (100.0%) ── content-parent(YouTube, pid=-1, closed channel, 0x4542b000, refcnt=1)
├──0 (100.0%) ── content-parent(YouTube, pid=-1, closed channel, 0x4555f400, refcnt=1)
└──0 (100.0%) ── content-parent(YouTube, pid=-1, closed channel, 0x45c86400, refcnt=1)

Closed apps are being leaked on the parent side.

Comment 13

[Nicholas Nethercote [inactive]]

I can reproduce the leaked content parents easily.

1. |adb shell| into the device.

2. Run |b2g-ps| in the shell, to get the pid of the Homescreen app.

3. |kill -15 <pid>|

4. Repeat steps 2 and 3 arbitrarily many times.


Sample output:

0 (100.0%) -- queued-ipc-messages
├──0 (100.0%) ── content-parent((Preallocated), pid=-1, closed channel, 0x45041c00, refcnt=1)
├──0 (100.0%) ── content-parent(Built-in Keyboard, pid=459, open channel, 0x46533c00, refcnt=17)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x43465800, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x44609400, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45031c00, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45040800, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45041000, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45041400, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x45e9cc00, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x46535000, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x46b9f800, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x471a5800, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x471a6000, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x47ce9400, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=-1, closed channel, 0x47ffc400, refcnt=1)
├──0 (100.0%) ── content-parent(Homescreen, pid=1494, open channel, 0x43e81800, refcnt=55)
└──0 (100.0%) ── content-parent(Usage, pid=371, open channel, 0x47eee800, refcnt=17)

Comment 14

[Nicholas Nethercote [inactive]]

Attachment: Script to automate leaking of content parents

Here's a script with which automates the steps to reproduce. It runs forever, you have to ctrl-c to kill it. It takes about 3 seconds for each iteration.

Comment 15

[Nicholas Nethercote [inactive]]

Hmm, I just used the script to create 400 leaked content parents. The main process's RSS actually dropped by a few MiB (from 50 to 45 MiB) though heap-unclassified rose from 6 to 7 MiB.

In contrast, in comment 12 we had only 71 leaked content parents but the main process was 75 MiB and heap-unclassified was 32 MiB. So I wonder if there's something else going on, or if repeatedly killing the Homescreen app is somehow less problematic than repeatedly killing a range of different apps.

Comment 16

[Nicholas Nethercote [inactive]]

BTW, it's unlikely that there's anything special about Quora. In the presence of any leak such as this one, eventually the available memory will drop in such a way that any site or app will have problems.

Comment 17

[Nicholas Nethercote [inactive]]

Attachment: DMD output for b2g process

Lots of unreported allocations going through TryRemoteBrowser().

Comment 18

[Preeti Raghunath(:Preeti)]

Andrew,

Please help with a fix here.

Comment 19

[Nicholas Nethercote [inactive]]

Kyle found that leaked observers are responsible, and he's working on a patch. From a run where I used my script to kill Homescreen over 1400 times:

3,203 (100.0%) -- observer-service-suspect
├──1,413 (44.11%) ── referent(topic=ask-children-to-exit-fullscreen)
├──1,412 (44.08%) ── referent(topic=phone-state-changed)
├────226 (07.06%) ── referent(topic=oop-frameloader-crashed)
└────152 (04.75%) ── referent(topic=inner-window-destroyed)

Comment 20

[Nicholas Nethercote [inactive]]

> Kyle found that leaked observers are responsible,

And so this might be a dup of bug 963259.

Comment 21

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Bugs 968536, 968542, and 968558 cover all of the entrained ContentParents I found.  That might not be all of the leak here though ... in particular I have a suspicion that Gaia is leaking blobs from crashed processed (probably screenshots or something).

Comment 22

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I think as is this doesn't block 1.3 anymore.

Can we retest with the patches from bugs 968536 and 968542?

Comment 23

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #22)
> I think as is this doesn't block 1.3 anymore.
> 
> Can we retest with the patches from bugs 968536 and 968542?

Well, if the key issues to causing this bug are resolved, then we can just close this out post verification. We don't need to leave the bug around with the blocking flag flipped back if the key issues have been resolved.

Flagging qawanted to retest from end user perspective.

Comment 24

[Nicholas Nethercote [inactive]]

I re-ran my script for 200 iterations:

533 (100.0%) -- observer-service-suspect
├──203 (38.09%) ── referent(topic=ask-children-to-exit-fullscreen)
├──169 (31.71%) ── referent(topic=oop-frameloader-crashed)
└──161 (30.21%) ── referent(topic=inner-window-destroyed)

So the phone-state-changed one (bug 968536) is definitely fixed, but ask-children-to-exit-fullscreen still looks like it's a problem.

Comment 25

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Sure ... I'm more interested in whether the bug as filed is reproducible.

Comment 26

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #25)
> Sure ... I'm more interested in whether the bug as filed is reproducible.

Oh - in that case, re-adding qawanted to see if this reproduces on the latest 1.3 build.

Comment 27

[Nicholas Nethercote [inactive]]

I did another 414 iterations just to be sure:

778 (100.0%) -- observer-service-suspect
├──617 (79.31%) ── referent(topic=ask-children-to-exit-fullscreen)
└──161 (20.69%) ── referent(topic=inner-window-destroyed)

khuey, are you not worried about ask-children-to-exit-fullscreen because it's a weak observer?

BTW, I had to use MOZ_IGNORE_NUWA_PROCESS=1 in order to make get_about_memory.py to terminate. Is this expected, or do I have to rebuild harder, somehow?

Comment 28

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Nicholas Nethercote [:njn] from comment #27)
> I did another 414 iterations just to be sure:
> 
> 778 (100.0%) -- observer-service-suspect
> ├──617 (79.31%) ── referent(topic=ask-children-to-exit-fullscreen)
> └──161 (20.69%) ── referent(topic=inner-window-destroyed)
> 
> khuey, are you not worried about ask-children-to-exit-fullscreen because
> it's a weak observer?

Right. It's not entraining a ContentParent.  It's not optimal, of course.

> BTW, I had to use MOZ_IGNORE_NUWA_PROCESS=1 in order to make
> get_about_memory.py to terminate. Is this expected, or do I have to rebuild
> harder, somehow?

Yes, that's expected, until we get all memory reporting to go through the parent.

Comment 29

[gbennett]

This repros on 1.3. I used a testers phone who has been running burirun1.3-3 all day and it repro'd first try. I was not able to get this to repro after only two hours of using my personal device.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140212004003
Gaia: ce17d5eae7b1893ae4397c814b10ae598fcbdb58
Gecko: ab07e61c2eb0
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 30

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can you provide the about:memory log from the phone that has been running burirun1.3-3 all day?

MOZ_IGNORE_NUWA_PROCESS=1 ./tools/get_about_memory.py

Comment 31

[gbennett]

Attachment: about-memory-4.zip

Here are the memory logs for the device we repro'd it on.

Comment 32

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Thanks.

Zero leaked ContentParents, which is good.  Heap unclassified is a little high.

├───9.15 MB (17.57%) ── heap-unclassified

Comment 33

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Nick, is is possible for you to figure out how to run this burirun thing and run it under DMD?

Comment 34

[Nicholas Nethercote [inactive]]

> Nick, is is possible for you to figure out how to run this burirun thing and
> run it under DMD?

If someone tells me what burirun is and points me at some documentation, perhaps! But running DMD isn't so hard (see https://wiki.mozilla.org/Performance/MemShrink/DMD) so perhaps gbennett could try it?

Comment 35

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

gbennett, is it possible for you to either run DMD according to the instructions in comment 34 or provide instructions on how to get and run burirun?

Comment 36

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #35)
> gbennett, is it possible for you to either run DMD according to the
> instructions in comment 34 or provide instructions on how to get and run
> burirun?

Does this require a custom build?

Comment 37

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Yes.

Comment 38

[gbennett]

Ah sorry I should have been more clear. Burirun is a full Buri test pass that we have been running this week. It would be very easy for me to do the latter of comment 35 as we have 6-10 testers running the test pass until the 20th.

Comment 39

[Jason Smith [:jsmith]]

(In reply to gbennett from comment #38)
> Ah sorry I should have been more clear. Burirun is a full Buri test pass
> that we have been running this week. It would be very easy for me to do the
> latter of comment 35 as we have 6-10 testers running the test pass until the
> 20th.

We don't have custom build environments setup in the QAnalyst office. If DMD is required, then I think the best option is to have someone who has a build environment setup to diagnose this.

Comment 40

[Ben Kelly [:bkelly, not reviewing]]

I've been running with DMD enabled for the last two or three weeks on my buri.  I haven't seen any noticeable impact on performance.  We should consider enabling it for all eng builds.

Comment 41

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Does QA test eng builds?  My experience with a regression range for an APZC bug led me to believe that they do not.

Comment 42

[Ben Kelly [:bkelly, not reviewing]]

Fair enough.  Jason, are there instructions how to run the tests used in a burirun?

Comment 43

[Jason Smith [:jsmith]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #41)
> Does QA test eng builds?  My experience with a regression range for an APZC
> bug led me to believe that they do not.

Yes - we do test eng builds for our UI automation & for on demand QA Wanted requests. If we want DMD enabled by default on eng builds, then let's file a bug in the rel eng component to enable DMD by default in eng builds.

Example - https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-hamachi-eng/latest/

(In reply to Ben Kelly [:bkelly] from comment #42)
> Fair enough.  Jason, are there instructions how to run the tests used in a
> burirun?

I don't follow you exactly. Can you clarify a bit more?

Comment 44

[Ben Kelly [:bkelly, not reviewing]]

Ok, I filed bug 975021 to possibly enable DMD in eng builds.

From IRC it sounds like Jason believes this still reproduces on quora.com intermittently with current v1.3.

Comment 45

[Jason Smith [:jsmith]]

QA Wanted - Can we retest this to determine reproducibility on the latest 1.3 build? I'd like to know if the reproduction rate is now tolerable enough to remove the blocking factor here.

Comment 46

[Sarah Parsons]

This have a very low reproduction rate, we were able to repro once on 2 out of the 3 Buri's we were using on the latest 1.3.

Environmental Variables:

BuildID: 20140224004003
Gaia: 5084b832f3b536f60ccdb38c14fd6162e5bfbac0
Gecko: 61875a0aa4cf
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 47

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Based on that I think we should call this fixed.

We will of course continue to investigate rising memory usage in the parent process over extended periods of time.