Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Description • 10 years ago

Compare memory growth logs in timestamp 

1) 2014-07-21 07:59:08 ==> about-memory-34 with 
2) 2014-07-20 19:11:20 ==> about-memory-0

For (1) , I can see : 
b2g USS: 68.2 MB.

DMD log shows: 

Unreported: ~1,638 blocks in stack trace record 1 of 900
 ~6,704,334 bytes (~6,704,334 requested / ~0 slop)
 16.62% of the heap (16.62% cumulative);  30.72% of unreported (30.72% cumulative)
 Allocated at
   replace_malloc /local/mnt/workspace/tkundu/kk36d18/gecko/memory/replace/dmd/DMD.cpp:1245 (0xb6f24898 libdmd.so+0x3898)
   moz_xmalloc /local/mnt/workspace/tkundu/kk36d18/gecko/memory/mozalloc/mozalloc.cpp:53 (0xb652bdea libxul.so+0x1406dea)
   pair /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_pair.h:68 (0xb4bfc3fe libxul.so+0x4ea3fe)
   std::priv::_Rb_tree<unsigned int, std::less<unsigned int>, std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket>, std::priv::_Select1st<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> >, std::priv::_MapTraitsT<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> >, std::allocator<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> > >::_M_insert(std::priv::_Rb_tree_node_base*, std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> const&, std::priv::_Rb_tree_node_base*, std::priv::_Rb_tree_node_base*) /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_tree.c:374 (0xb4bfc464 libxul.so+0x4ea464)
   ~_Rb_tree /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_tree.h:414 (0xb4d8f19c libxul.so+0x67d19c)
   ~nsRefPtr /local/mnt/workspace/tkundu/kk36d18/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsAutoPtr.h:869 (0xb4d9dcfc libxul.so+0x68bcfc)
   mozilla::layers::ClientLayerManager::BeginTransaction() /local/mnt/workspace/tkundu/kk36d18/gecko/gfx/layers/client/ClientLayerManager.cpp:178 (0xb4d9ce6a libxul.so+0x68ae6a)
   PresShell::Paint(nsView*, nsRegion const&, unsigned int) /local/mnt/workspace/tkundu/kk36d18/gecko/layout/base/nsPresShell.cpp:6120 (0xb540ec70 libxul.so+0xcfcc70)
   ....... (see in attached about-memory-34 DMD log file) 


We are seeing 61 FDs are opened with '/data/local/webapps/marketplace.firefox.com/application.zip' lsof logs for this timestamp and please also note total opened FDs at this timestamp is 392 for b2g process. 


and for (2), I can see :
b2g USS 50.0MB

DMD log shows: 

Unreported: ~47 blocks in stack trace record 3 of 696
 ~192,371 bytes (~192,371 requested / ~0 slop)
 0.79% of the heap (10.13% cumulative);  2.28% of unreported (29.31% cumulative)
 Allocated at
   replace_malloc /local/mnt/workspace/tkundu/kk36d18/gecko/memory/replace/dmd/DMD.cpp:1245 (0xb6f24898 libdmd.so+0x3898)
   moz_xmalloc /local/mnt/workspace/tkundu/kk36d18/gecko/memory/mozalloc/mozalloc.cpp:53 (0xb652bdea libxul.so+0x1406dea)
   pair /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_pair.h:68 (0xb4bfc3fe libxul.so+0x4ea3fe)
   std::priv::_Rb_tree<unsigned int, std::less<unsigned int>, std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket>, std::priv::_Select1st<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> >, std::priv::_MapTraitsT<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> >, std::allocator<std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> > >::_M_insert(std::priv::_Rb_tree_node_base*, std::pair<unsigned int const, mozilla::layers::APZTestData::Bucket> const&, std::priv::_Rb_tree_node_base*, std::priv::_Rb_tree_node_base*) /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_tree.c:374 (0xb4bfc464 libxul.so+0x4ea464)
   ~_Rb_tree /local/mnt/workspace/tkundu/kk36d18/gecko/build/stlport/stlport/stl/_tree.h:414 (0xb4d8f19c libxul.so+0x67d19c)
   ~nsRefPtr /local/mnt/workspace/tkundu/kk36d18/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsAutoPtr.h:869 (0xb4d9dcfc libxul.so+0x68bcfc)
   mozilla::layers::ClientLayerManager::BeginTransaction() /local/mnt/workspace/tkundu/kk36d18/gecko/gfx/layers/client/ClientLayerManager.cpp:178 (0xb4d9ce6a libxul.so+0x68ae6a)
   PresShell::Paint(nsView*, nsRegion const&, unsigned int) /local/mnt/workspace/tkundu/kk36d18/gecko/layout/base/nsPresShell.cpp:6120 (0xb540ec70 libxul.so+0xcfcc70)
   .............. (see in attached about-memory-0 DMD log file) 

We are seeing ONLY ONE FD is opened with '/data/local/webapps/marketplace.firefox.com/application.zip' lsof logs for this timestamp and total FD is 314 in this timestamp.



For both (1) and (2) : 
b2g-procrank shows only b2g, homescreen, NUWA, preallocated and keyboard is running at this time and all memory reports are collected with --minimize option [1]. Important thing is that b2g is not releasing USS memory even with '--minimize' option.



b2g is hitting 80MB at some point and getting killed finally on 256MB device. 

Can we get a fix for above 'moz_xmalloc' allocations ? 
Are we leaking FD '/data/local/webapps/marketplace.firefox.com/application.zip' over time period ? 


[1] while true; do   adb shell date >> memory_logs_timestamp.txt && MOZ_IGNORE_NUWA_PROCESS=1 ./device/qcom/b2g_common/mozilla-b2g/tools/get_about_memory.py --minimize --gecko-objdir=./out/target/product/msm8610/obj/objdir-gecko/ --gonk-objdir=./out --product=msm8610 && sleep 1200 ; done


FULL logs are at : https://drive.google.com/file/d/0B1cSMS8_GuAEMFFPdmVZSGZzSjA/edit?usp=sharing

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 1 • 10 years ago

STR: 
1) Run camera, camcorder, SMS, call, airplane_on_off , bt_on_off , wifi_on_off for atleast 18 hours. 

I know STR will be very difficult to reproduce. But we can start with two debugging two issues (also mentioned in Comment 0) :

1) Can we get a fix for above 'moz_xmalloc' allocations ? 
2) Are we leaking FD '/data/local/webapps/marketplace.firefox.com/application.zip' over time period ?

	Jason Smith [:jsmith]
	Comment 2 • 10 years ago

Mike - Can someone from your team investigate this issue?

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 3 • 10 years ago

24.24 MB (100.0%) -- explicit
├──12.88 MB (53.12%) ── heap-unclassified
├───6.52 MB (26.90%) ++ js-non-window
├───2.63 MB (10.83%) ++ images/content/raster
├───0.03 MB (00.12%) ++ window-objects
├───1.04 MB (04.30%) ++ heap-overhead
├───0.48 MB (01.97%) ++ xpconnect
├───0.35 MB (01.45%) ++ (11 tiny)
└───0.32 MB (01.31%) ++ dmd

Most of this in APZC code.  Why are we storing test data in a production build anyways?

	Hubert Figuiere [:hub]
	Comment 4 • 10 years ago

Isn't that related to what I see in bug 1027649

	Kyle Huey (Exited; not receiving bugmail, old account, do not use)
	Comment 5 • 10 years ago

Maybe.  There's nothing in that bug that would help identify the cause.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 6 • 10 years ago

Botond, can you take a look at this bug?  I think the only way for APZTestData to be leaked is for the whole ClientLayerManager to be leaked, but I could be wrong.  I'm not sure if we do want APZTestData in the release build (if we do, the name for the class is less than optimal :), and if we don't, we should take care of that.  Either way, this could be pointing to a ClientLayerManager leak, and maybe we didn't see it before because it was much smaller?
As a quick remedy, can we disable the APZTestData in the release build to see if we get the memory leak under control?

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 7 • 10 years ago

Botond, if this is a ClientLayerManager leak, can you assign to :nical instead?

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 8 • 10 years ago

Sotaro was mentioning that we should be in good shape (e.g., not leaking) ClientLayerManagers and such, so let's share all the information we have.

	Sotaro Ikeda [:sotaro]
	Comment 9 • 10 years ago

(In reply to Milan Sreckovic [:milan] from comment #8)
> Sotaro was mentioning that we should be in good shape (e.g., not leaking)
> ClientLayerManagers and such, so let's share all the information we have.

I confirmed about ClientLayerManagers destruction during Bug 1004191. On the STR in Bug 1004191 there was no ClientLayerManagers leak.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 10 • 10 years ago

Botond thinks this is just the accumulation of the empty APZTestData containers (the actual data is behind the pref), so we'll put the container creation behind the same pref.

	Botond Ballo [:botond] Assignee
	Comment 11 • 10 years ago

(In reply to Milan Sreckovic [:milan] from comment #10)
> Botond thinks this is just the accumulation of the empty APZTestData
> containers (the actual data is behind the pref), so we'll put the container
> creation behind the same pref.

To expand on that a bit: the APZ test logging code is compiled into release builds, but it's pref'd off. However, there's a deficiency in how be pref'd it off. The APZ test data consists of a bucket for each paint, and there are two places in the code that touch it: 1) at the beginning of each paint, we create a new empty bucket for that paint; 2) at various points in the paint, we write data into the current bucket. Only (2) is pref'd off, (1) is not. This means that over a long time of using the phone, the empty buckets for each paint accumulate.

It's straightforward to pref the creation of empty buckets off as well. Patch forthcoming.

	Botond Ballo [:botond] Assignee
	Comment 13 • 10 years ago

This seems simple enough to land without a Try push. Will land when the tree opens.

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 14 • 10 years ago

(In reply to Botond Ballo [:botond] from comment #13)
> This seems simple enough to land without a Try push. Will land when the tree
> opens.

I am trying it . I will update soon :)

	Botond Ballo [:botond] Assignee
	Comment 15 • 10 years ago
landing

https://hg.mozilla.org/integration/mozilla-inbound/rev/c1ea5a8280d7

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 16 • 10 years ago

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/b920a17bab70 for causing at least the Gip test failures in https://tbpl.mozilla.org/php/getParsedLog.php?id=44381024&tree=Mozilla-Inbound

There were also OSX tp failures starting around the same time, though it wasn't run on the push where this patch landed, so I'm not completely sure if they were caused by this bug: https://tbpl.mozilla.org/php/getParsedLog.php?id=44382853&tree=Mozilla-Inbound

Windows debug crashtests also started failing around the same time, but again, they didn't run on this push, so I'm not sure this patch caused them: https://tbpl.mozilla.org/php/getParsedLog.php?id=44382969&tree=Mozilla-Inbound



I'll retrigger jobs to bisect where they started failing, and will follow up with the results.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 17 • 10 years ago

So, the windows crashtests do seem to have started with this as well: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=debug%20test%20crashtest&rev=c1ea5a8280d7


And the tp failures also started up on this landing.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 18 • 10 years ago

For the record, the crashtest failures aren't constant, as they sometimes pass just fine.

	Joel Maher ( :jmaher ) (UTC -8)
	Comment 19 • 10 years ago

keep in mind this has a lot of performance impact when we look to reland it, here is what we have:
+--------------------+--------------------------------------+---------+
| platform           | test                                 | percent |
+--------------------+--------------------------------------+---------+
| MacOSX 10.8        | Session Restore no Auto Restore Test | -11.8%  |
| MacOSX 10.8        | Ts, Paint                            | -35%    |
| MacOSX 10.8        | Paint                                | -60.4%  |
| MacOSX 10.8        | a11y Row Major MozAfterPaint         | -47.4%  |
| MacOSX 10.6 (rev4) | Paint                                | -29.3%  |
| MacOSX 10.6 (rev4) | a11y Row Major MozAfterPaint         | -22%    |
| MacOSX 10.6 (rev4) | Session Restore no Auto Restore Test | +9.88%  |
| MacOSX 10.6 (rev4) | Ts, Paint                            | -26.8%  |
| MacOSX 10.6 (rev4) | Session Restore Test                 | +4.38%  |
| MacOSX 10.6 (rev4) | TP5 Scroll                           | +3.72%  |
| MacOSX 10.8        | TP5 Scroll                           | +14.1%  |
| WINNT 6.1 (ix)     | Ts, Paint                            | -3.92%  |
+--------------------+--------------------------------------+---------+

so ts_paint, paint, a11y all saw regressions, but tp5o scroll saw an improvement.  Please look into the talos number prior to relanding to minimize the regressions!

	Joel Maher ( :jmaher ) (UTC -8)
	Comment 20 • 10 years ago

wait there are more improvements than that list, in fact, we seem to have a lot of improvements in:
tart, cart, tscroll-asap, tresize!

And larger ones!

Here is the alerts from the backout (negative values are actually improvements from this patch, positive values here are regressions from this patch:
+--------------------+--------------------------------------+---------+
| platform           | test                                 | percent |
+--------------------+--------------------------------------+---------+
| MacOSX 10.6 (rev4) | Session Restore no Auto Restore Test | -10.7%  |
| MacOSX 10.6 (rev4) | Session Restore Test                 | -4.17%  |
| MacOSX 10.6 (rev4) | a11y Row Major MozAfterPaint         | +17.7%  |
| MacOSX 10.6 (rev4) | Ts, Paint                            | +21.3%  |
| MacOSX 10.6 (rev4) | Paint                                | +22.5%  |
| MacOSX 10.8        | TP5 Scroll                           | -16.3%  |
| MacOSX 10.6 (rev4) | TP5 Scroll                           | -3.57%  |
| MacOSX 10.6 (rev4) | Customization Animation Tests        | -50.3%  |
| MacOSX 10.6 (rev4) | tscroll-ASAP                         | -9.51%  |
| MacOSX 10.6 (rev4) | Tab Animation Test                   | -106%   |
| MacOSX 10.8        | a11y Row Major MozAfterPaint         | +30.6%  |
| MacOSX 10.6 (rev4) | TResize                              | +81.4%  |
| MacOSX 10.8        | Session Restore no Auto Restore Test | +9.08%  |
| MacOSX 10.8        | Paint                                | +36.7%  |
| MacOSX 10.8        | Customization Animation Tests        | -35%    |
| MacOSX 10.8        | tscroll-ASAP                         | -20.5%  |
| MacOSX 10.8        | Tab Animation Test                   | -119%   |
| MacOSX 10.8        | TResize                              | +84.7%  |
+--------------------+--------------------------------------+---------+

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 21 • 10 years ago

Comment on attachment 8460415 [details] [diff] [review]
Only create an APZ test data bucket for a paint if APZ test logging is enabled

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

Don't know the code, but this looks suspicious...

::: gfx/layers/client/ClientLayerManager.cpp
@@ +170,3 @@
>      ++mPaintSequenceNumber;
>      mApzTestData.StartNewPaint(mPaintSequenceNumber);
>    }

Did you want this instead?

if (!mIsRepeatTransaction) {
  ++mPaintSequenceNumber;
  if (gfxPrefs::APZTestLogginEnabled()) {
    mApzTestData.StartNewPaint(mPaintSequenceNumber);
  }
}

	Botond Ballo [:botond] Assignee
	Comment 22 • 10 years ago

(In reply to Milan Sreckovic [:milan] from comment #21)
> Don't know the code, but this looks suspicious...
> 
> ::: gfx/layers/client/ClientLayerManager.cpp
> @@ +170,3 @@
> >      ++mPaintSequenceNumber;
> >      mApzTestData.StartNewPaint(mPaintSequenceNumber);
> >    }
> 
> Did you want this instead?
> 
> if (!mIsRepeatTransaction) {
>   ++mPaintSequenceNumber;
>   if (gfxPrefs::APZTestLogginEnabled()) {
>     mApzTestData.StartNewPaint(mPaintSequenceNumber);
>   }
> }

I don't believe so. The paint sequence number is only used by the APZ testing framework, and any code that relies on it is also pref'd off with the same pref.

I'll run the failing tests on Try with this change just to be absolutely sure, as I don't really have other ideas.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 23 • 10 years ago

As I said, I don't know the code.  I just saw it being passed via IPC, but didn't track down what happens on the other side...

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 24 • 10 years ago

I'm also assuming there are no assertions in the debug, otherwise I'd check if gfxPrefs is getting initialized sooner than before.

	Botond Ballo [:botond] Assignee
	Comment 25 • 10 years ago

(In reply to Milan Sreckovic [:milan] from comment #24)
> I'm also assuming there are no assertions in the debug, otherwise I'd check
> if gfxPrefs is getting initialized sooner than before.

Unfortunately, the Gip tests seem to only be run on Opt builds. I'll look into the possibility of running them locally on a debug build.

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 26 • 10 years ago

Comment 19 gives us some alert. We are waiting to see final patch for this memleak issue .

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 27 • 10 years ago

We're working on the final patch, but the only issue that would resolve is test specific - you should be able to test with the patch as is when doing normal running.

	Joel Maher ( :jmaher ) (UTC -8)
	Comment 28 • 10 years ago

have you guys looked at the performance regressions introduced by this?

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 29 • 10 years ago

Haven't looked at performance regressions.  Don't believe there should be any once the code is correct; if after that we're still seeing some, we'll investigate.

	Botond Ballo [:botond] Assignee
	Comment 30 • 10 years ago
try

Implementing Milan's suggestion from comment 21 appears to fix the failing tests, and not introduce performance regressions, as can be seen in this full (including Talos) Try push: https://tbpl.mozilla.org/?tree=Try&rev=1b60c98820db

While I don't understand why this change makes a difference, since this is a high-priority issue and we have a green Try run, I'm going to land this fix, and continue to investigate independently to understand the cause.

	Botond Ballo [:botond] Assignee
	Comment 31 • 10 years ago
landing

https://hg.mozilla.org/integration/mozilla-inbound/rev/805d74b562a2

	Botond Ballo [:botond] Assignee
	Comment 32 • 10 years ago

(In reply to Botond Ballo [:botond] from comment #30)
> Implementing Milan's suggestion from comment 21 appears to fix the failing
> tests, and not introduce performance regressions, as can be seen in this
> full (including Talos) Try push:
> https://tbpl.mozilla.org/?tree=Try&rev=1b60c98820db
> 
> While I don't understand why this change makes a difference, since this is a
> high-priority issue and we have a green Try run, I'm going to land this fix,
> and continue to investigate independently to understand the cause.

Turns out I had done something very silly in my original bug 961289 patch: I accidentally switched the order of two arguments, 'bool aScheduleComposite' and 'uint32_t aPaintSequenceNumber', to one of the functions on the path from the client layer manager to the compositor.

As a result, we would schedule a composite whenever the sequence number was greater than zero, rather than whenever aScheduleComposite was true. This mostly worked out because the sequence number is greater than zero on every paint except the first, and aScheduleComposite is always true except in some scenarios involving plugins.

Now that I conditioned the incrementing of the sequence number on the pref being on, though, we stopped scheduling composites, and experienced various test failures as a result.

This patch puts the incrementing of the sequence number back under the pref, where it should be, and implements the proper fix for the test failures - fixing the order-of-arguments bug - instead.

	Botond Ballo [:botond] Assignee
	Comment 33 • 10 years ago

Sorry, wrong patch.

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 34 • 10 years ago

(In reply to Botond Ballo [:botond] from comment #33)
> Created attachment 8462101 [details] [diff] [review]
> Proper fix for test failures
> 
> Sorry, wrong patch.

We want to ask our stability team to test this patch for memleak issue. It seems like we need to apply two patches in sequence for this
1)  Comment 12 and 
2)  Comment 33 .

Could you please confirm ?

	Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me) Reporter
	Comment 35 • 10 years ago

patch from Comment 33 does not apply cleanly on FFOS v2.0. Could you please rebase for FFOS 2.0 and confirm us again ?

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 36 • 10 years ago

Comment on attachment 8462101 [details] [diff] [review]
Proper fix for test failures

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

Make sure to run it through try before landing. and s/tn/kats/ in the commit message.

	Botond Ballo [:botond] Assignee
	Comment 37 • 10 years ago

For convenience, posting a combined patch of Part 1 and Part 2.

This one applies to trunk. I will post a 2.0 one as well.

	Botond Ballo [:botond] Assignee
	Comment 38 • 10 years ago

Here's the combined patch for 2.0.

	Botond Ballo [:botond] Assignee
	Comment 39 • 10 years ago

Marking leave-open until the second patch lands on m-c as well.

	Botond Ballo [:botond] Assignee
	Comment 40 • 10 years ago
green try

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #36)
> Make sure to run it through try before landing. 

Try push: https://tbpl.mozilla.org/?tree=Try&rev=a540ac8ce9e4

> and s/tn/kats/ in the commit message.

Done.

	Botond Ballo [:botond] Assignee
	Comment 41 • 10 years ago
landing

https://hg.mozilla.org/integration/mozilla-inbound/rev/c4509282c6ad

	Timothy Nikkel (:tnikkel)
	Comment 42 • 10 years ago

(In reply to Botond Ballo [:botond] from comment #40)
> (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #36)
> > and s/tn/kats/ in the commit message.
> 
> Done.

Looks like this didn't get done, oops :)

	Botond Ballo [:botond] Assignee
	Comment 43 • 10 years ago

(In reply to Timothy Nikkel (:tn) from comment #42)
> (In reply to Botond Ballo [:botond] from comment #40)
> > (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #36)
> > > and s/tn/kats/ in the commit message.
> > 
> > Done.
> 
> Looks like this didn't get done, oops :)

Oh, whoops! I amended the patch, but then pushed the old patch to inbound... sorry about that.

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 44 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/805d74b562a2
https://hg.mozilla.org/mozilla-central/rev/c4509282c6ad

	Botond Ballo [:botond] Assignee
	Comment 45 • 10 years ago

Closing now that both patches have landed.

	Ryan VanderMeulen [:RyanVM]
	Comment 46 • 10 years ago

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/43a2ecfe68b2

	Yeojin Chung [:YeojinC]
	Comment 47 • 10 years ago

No STR is present to create test case to address bug.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 48 • 10 years ago

(In reply to Yeojin Chung [:YeojinC] from comment #47)
> No STR is present to create test case to address bug.

Right - it's a fairly simple STR, but it takes a long time.  Basically, just scroll the phone for 8 hours and watch the memory usage grow.  The bug was "losing" a small amount of memory, but it was doing it on refresh, so it added up.

	Adam Alldredge [:AdamA][Inactive]
	Comment 49 • 10 years ago

We are unable to verify this issue because it is a backend problem.