Closed Bug 1038958 Opened 10 years ago Closed 10 years ago

potential b2g memory leak which is causing OOM killer to kill b2g.

Categories

(Core :: Graphics: Layers, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla33
blocking-b2g 2.0+
Tracking Status
firefox32 --- fixed
firefox33 --- fixed
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: tkundu, Assigned: sotaro)

References

Details

(Keywords: memory-footprint, perf, Whiteboard: [caf priority: p1][CR 691739][MemShrink])

STR:
1) Call any phone from test phone
2) Send sms to another from test phone 
3) Repeat (1) and (2) infinitely. b2g will be rebooted multiple times within 24 hours.

Logs: https://drive.google.com/file/d/0B1cSMS8_GuAEcnFfeUY2WTE2WlU/edit?usp=sharing


We can see that b2g is killed. See logs for timestamp 2014-07-14 23:16:11. 

Useful information:
1) We are seeing lots of FD is created with "anon_inode:sync_fence" . See lsof logs.
2) Huge ION allocation 50MB just before crash . See ion.log*.txt
3) USS reaches 80 MB when it crashes. 

Unfortunately, I didn't collect gecko memory report when this happened. I will update with DMD report soon.

@sotaro : Could you please help me to understand if anyone is leaking "anon_inode:sync_fence" from lsof logs ?
Whiteboard: [CR 691739]
>@sotaro : Could you please help me to understand if anyone is leaking "anon_inode:sync_fence" from lsof logs ?

Okey, I am going to check it.
@sotaro : please note that this is reproduced with fix from bug 1037360. So we didn't observe any VSS memory leak in this use case.
Flags: needinfo?(sotaro.ikeda.g)
blocking-b2g: --- → 2.0?
(In reply to Tapas Kumar Kundu from comment #2)
> @sotaro : please note that this is reproduced with fix from bug 1037360. So
> we didn't observe any VSS memory leak in this use case.

I had offline discussion with Inder on this. This is a spin-off from 1037360. CAF was expecting the crash and memory lead to be handled by the patch in 1037360. So CAF spun this bug to handle the crash here. They are getting dumps/logs as necessary.
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → sotaro.ikeda.g
I have found a sync fence fd leak in Color layer handling in HWC Composition path. I will provide a patch to Tapas, to check if it helps.
(In reply to Sushil from comment #4)
> I have found a sync fence fd leak in Color layer handling in HWC Composition
> path. I will provide a patch to Tapas, to check if it helps.

I will test with this patch and update here if I see more leaks.
Whiteboard: [CR 691739] → [caf priority: p1][CR 691739]
Exact scripts to reproduce this issue :

1) |gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/test_dialer.py| to place call
2) |gcli sendsms| to send an sms
3) Repeat 1 and 2 infinitely.

Mozilla has already access to 1 and 2 . This will help to reproduce this issue for everyone.
Sotaro,

I suspected release fence fd leak at [1] and [2]. So I added "close(fd)" at [1] & [2]. And moved fence creation from [3] to [4]. Tapas tested the patch and verified that it does not help in reducing sync fence fd counts. So this is not the root cause of this bug then, can you check for any other potential sync fence fd leak? It can happen in GPU Composition path as well.

[1]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#726
[2]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#730
[3]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#722
[4]: http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.cpp#732
Flags: needinfo?(sotaro.ikeda.g)
Tapas, can we also have get_about_memory.py result?
Flags: needinfo?(tkundu)
Flags: needinfo?(sotaro.ikeda.g)
> Useful information:
> 1) We are seeing lots of FD is created with "anon_inode:sync_fence" . See lsof logs.
> 2) Huge ION allocation 50MB just before crash . See ion.log*.txt
> 3) USS reaches 80 MB when it crashes. 


From huge ion alloation, I wondering if a possibility of leaking GrallocTextureHostOGL, it holds gralloc buffer(ion) and release Fence.
(In reply to Sushil from comment #7)
> Sotaro,
> 
> I suspected release fence fd leak at [1] and [2]. So I added "close(fd)" at
> [1] & [2]. And moved fence creation from [3] to [4]. Tapas tested the patch
> and verified that it does not help in reducing sync fence fd counts. So this
> is not the root cause of this bug then, can you check for any other
> potential sync fence fd leak? It can happen in GPU Composition path as well.
> 
> [1]:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.
> cpp#726
> [2]:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.
> cpp#730
> [3]:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.
> cpp#722
> [4]:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/HwcComposer2D.
> cpp#732

In my understanding, the above code does not leak fence. If a fence file descriptor is valid, the descriptor is wrapped by android::Fence by the following code.

  > sp<Fence> fence = new Fence(fd);

When the android::Fence object is destroyed, the descriptor automatically deleted.

gecko basically does not handle raw file descriptor except HwcComposer2D and ParamTraits<FenceHandle>. Instead, gecko handles android::Fence objects. The android::Fence objects are stored in GrallocTextureHostOGL.
(In reply to Tapas Kumar Kundu from comment #6)
> Exact scripts to reproduce this issue :
> 
> 1)
> |gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/
> test_dialer.py| to place call
> 2) |gcli sendsms| to send an sms
> 3) Repeat 1 and 2 infinitely.
> 
> Mozilla has already access to 1 and 2 . This will help to reproduce this
> issue for everyone.

Tapas, which UI is shown on the phone's display during testing? For example, if homescreen is shown, there seems no update to ui.
(In reply to Sotaro Ikeda [:sotaro] from comment #11)
> (In reply to Tapas Kumar Kundu from comment #6)
> > Exact scripts to reproduce this issue :
> > 
> > 1)
> > |gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/
> > test_dialer.py| to place call
> > 2) |gcli sendsms| to send an sms
> > 3) Repeat 1 and 2 infinitely.
> > 
> > Mozilla has already access to 1 and 2 . This will help to reproduce this
> > issue for everyone.
> 
> Tapas, which UI is shown on the phone's display during testing? For example,
> if homescreen is shown, there seems no update to ui.

Sorry, I wrote the question just by checking 2). 2) seems not update the ui if the message app is not shown.
(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> (In reply to Sotaro Ikeda [:sotaro] from comment #11)
> > (In reply to Tapas Kumar Kundu from comment #6)
> > > Exact scripts to reproduce this issue :
> > > 
> > > 1)
> > > |gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/
> > > test_dialer.py| to place call
> > > 2) |gcli sendsms| to send an sms
> > > 3) Repeat 1 and 2 infinitely.
> > > 
> > > Mozilla has already access to 1 and 2 . This will help to reproduce this
> > > issue for everyone.
> > 
> > Tapas, which UI is shown on the phone's display during testing? For example,
> > if homescreen is shown, there seems no update to ui.
> 
> Sorry, I wrote the question just by checking 2). 2) seems not update the ui
> if the message app is not shown.

Hey sotaro, I am not understanding your question properly. Do you meant to say that gaiatest is not sending sms ? Did you already try my STR ? 

I tried with get_about_memory.py with my DMD enabled build but it did not generate memory report wben memory usage was high. I am re-running same STR to collect memory report again. 

BTW, comment 9 and comment 10 seems to be very interesting. Do you think that we need to add logs somewhere in gecko to conclude it quickly ? If so then please provide me a patch to collect logs.
Flags: needinfo?(tkundu) → needinfo?(sotaro.ikeda.g)
DMD gecko memory report after 1 hour of running stability automation https://drive.google.com/file/d/0B1cSMS8_GuAEUVdoNk1DNnF3RWM/edit?usp=sharing

Sotaro : Do you think that we are leaking from this code : (see about-mempory-6 DMD data and compare it with about-memory-5 DMD data)


Unreported: 11 blocks in stack trace record 1 of 791
 16,175,104 bytes (16,135,845 requested / 39,259 slop)
 37.36% of the heap (37.36% cumulative);  63.02% of unreported (63.02% cumulative)
 Allocated at
   replace_malloc /local/mnt/workspace/tkundu/kk36t8th/gecko/memory/replace/dmd/DMD.cpp:1245 (0xb6f70898 libdmd.so+0x3898)
   mozilla::gfx::AlignedArray<unsigned char, 16>::Realloc(unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/gfx/2d/Tools.h:123 (0xb4d4b074 libxul.so+0x634074)
   mozilla::gfx::Factory::CreateDataSourceSurface(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SurfaceFormat) /local/mnt/workspace/tkundu/kk36t8th/gecko/gfx/2d/Factory.cpp:695 (0xb4d385f2 libxul.so+0x6215f2)
   mozilla::TemporaryRef<mozilla::gfx::DataSourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dcff1a libxul.so+0x6b8f1a)
   mozilla::TemporaryRef<mozilla::gfx::SourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dd018a libxul.so+0x6b918a)
   mozilla::TemporaryRef<mozilla::gfx::SourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dcd8ea libxul.so+0x6b68ea)
   already_AddRefed<mozilla::layers::Image>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb4dce768 libxul.so+0x6b7768)
   nsImageRenderer::GetContainer(mozilla::layers::LayerManager*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsCSSRendering.cpp:5089 (0xb542f8f4 libxul.so+0xd188f4)
   already_AddRefed<mozilla::layers::ImageContainer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb543ceb4 libxul.so+0xd25eb4)
   nsDisplayBackgroundImage::GetContainer(mozilla::layers::LayerManager*, nsDisplayListBuilder*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:2059 (0xb543d088 libxul.so+0xd26088)
   mozilla::ThebesLayerData::CanOptimizeImageLayer(nsDisplayListBuilder*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:1723 (0xb541661a libxul.so+0xcff61a)
   mozilla::ContainerState::PopThebesLayerData() /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:1911 (0xb5419b48 libxul.so+0xd02b48)
   nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::Length() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsTArray.h:368 (discriminator 1) (0xb541a1d8 libxul.so+0xd031d8)
   mozilla::ContainerState::GetChildrenBounds() /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:533 (0xb541b146 libxul.so+0xd04146)
   already_AddRefed<mozilla::layers::ContainerLayer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e374ba libxul.so+0xd284ba)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e12698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e1313c libxul.so+0xd0413c)
   already_AddRefed<mozilla::layers::ContainerLayer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e373d6 libxul.so+0xd283d6)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e12698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e1313c libxul.so+0xd0413c)
   nsDisplayOwnLayer::BuildLayer(nsDisplayListBuilder*, mozilla::layers::LayerManager*, mozilla::ContainerLayerParameters const&) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:3580 (0xb543cb10 libxul.so+0xd25b10)
   nsDisplaySubDocument::BuildLayer(nsDisplayListBuilder*, mozilla::layers::LayerManager*, mozilla::ContainerLayerParameters const&) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:3615 (0xb5441756 libxul.so+0xd2a756)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e12698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e1313c libxul.so+0xd0413c)
It seems like this is also happening with gpucomp
Sotara, on the call we discussed three options that may cause this issue, one of them was HwComposer, and that seems to be ruled out as the issue is also happening with gpucomp per comment #15. What were our other two suspects ?
(In reply to Tapas Kumar Kundu from comment #6)
> Exact scripts to reproduce this issue :
> 
> 1)
> |gaia/tests/python/gaia-ui-tests/gaiatest/tests/functional/dialer/
> test_dialer.py| to place call
> 2) |gcli sendsms| to send an sms
> 3) Repeat 1 and 2 infinitely.
> 
> Mozilla has already access to 1 and 2 . This will help to reproduce this
> issue for everyone.

With rob's help, I got the environment to do the STR :-) I am going to investigate about it.
Sotaro, 1 more easy way to see leak in sync fence fd.

STR:
1. At home screen: ~ 320 (adb shell lsof | grep "sync_fence")
2. Launch Phone app: ~328 (Makes sense as new buffers are created and home screen still is still alive)
3. Exit Phone app and come back to Home screen: 387 (It seems leak is in App exit scenario)
4. Long press Home button and kill Phone app: 372 (Makes sense since we destroyed some buffers)

So it increases "sync_fence" fd from 320 to 372 in above steps, it seems leak is in App exit step.
(In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please] from comment #16)
> Sotara, on the call we discussed three options that may cause this issue,
> one of them was HwComposer, and that seems to be ruled out as the issue is
> also happening with gpucomp per comment #15. What were our other two
> suspects ?

From fence leaking in b2g point of view, there seems following possibilities.
- [1] gecko leaks GrallocTextureHostOGL
- [2] bad things happen around gecko IPC
- [3] bad things happen around HwcComposer2D
- [4] bad things happen in hw composer.
lsof logs suggests that both anon_inode:dmabuf and anon_inode:sync_fence are increasing over period
Hmm, I tried the STR in Comment 18. But I do not saw the increase of "sync_fence" on latest v2.0 flame with 273MB RAM. I checked the fence count by using
  > adb shell lsof | grep "sync_fence" | wc -l

After boot, the count was around 40 on homescreen. By doing the STR, the count rise to around 90 at most. But the count increase stop at that point.
Flags: needinfo?(sotaro.ikeda.g)
Sushil, do you use vertical homescreen on your phone?
Flags: needinfo?(sushilchauhan)
Yes, I see vertical home screen on v2.0 build. For Comment 21, why should the count increase from 40 to 90, even though we have already killed Phone App in Step 4. So I mentioned leak in App exit scenario.
Flags: needinfo?(sushilchauhan)
One more logs with DMD report: 

https://drive.google.com/file/d/0B1cSMS8_GuAEUU9jTXRXa0pFTFU/edit?usp=sharing

I have 3 important notes for this bug : 

1) in about-memory-2 , I am seeing big allocations (22MB) from graphics layer tree [1] . 
   A) There is two preallocated process (bug 1038854), Only homescreen process, NUWA and b2g is running. Then why are we seeing big increment in DMD report from this place between about-memory-0 to about-memory-2? Memory allocation increases almost 20MB from code [1] and b2g is not releasing this memory even with |get-about-memory.py --minimize| command. 
   B) I am seeing 70 fds of anon_inode:sync_fence and 110 fds of anon_inode:dmabuf at timestamp  2014-07-16 15:09:35 in lsof logs even after running |get-about-memory.py --minimize| command and only homescreen, b2g, nuwa and two preallocated process (bug 1038854) is running. 


My guess is that both (A) and (B) is causing leak. @sotaro: Can we get a fix for (A) quickly? Please give your opinion. BTW I am using vertical homescreen.


[1] Unreported: 15 blocks in stack trace record 1 of 777
 22,056,960 bytes (22,003,425 requested / 53,535 slop)
 45.62% of the heap (45.62% cumulative);  70.77% of unreported (70.77% cumulative)
 Allocated at
   replace_malloc /local/mnt/workspace/tkundu/kk36t8th/gecko/memory/replace/dmd/DMD.cpp:1245 (0xb6f56898 libdmd.so+0x3898)
   mozilla::gfx::AlignedArray<unsigned char, 16>::Realloc(unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/gfx/2d/Tools.h:123 (0xb4d4b074 libxul.so+0x634074)
   mozilla::gfx::Factory::CreateDataSourceSurface(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SurfaceFormat) /local/mnt/workspace/tkundu/kk36t8th/gecko/gfx/2d/Factory.cpp:695 (0xb4d385f2 libxul.so+0x6215f2)
   mozilla::TemporaryRef<mozilla::gfx::DataSourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dcff1a libxul.so+0x6b8f1a)
   mozilla::TemporaryRef<mozilla::gfx::SourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dd018a libxul.so+0x6b918a)
   mozilla::TemporaryRef<mozilla::gfx::SourceSurface>::drop() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/mozilla/RefPtr.h:309 (0xb4dcd8ea libxul.so+0x6b68ea)
   already_AddRefed<mozilla::layers::Image>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb4dce768 libxul.so+0x6b7768)
   nsImageRenderer::GetContainer(mozilla::layers::LayerManager*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsCSSRendering.cpp:5089 (0xb542f8f4 libxul.so+0xd188f4)
   already_AddRefed<mozilla::layers::ImageContainer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb543ceb4 libxul.so+0xd25eb4)
   nsDisplayBackgroundImage::GetContainer(mozilla::layers::LayerManager*, nsDisplayListBuilder*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:2059 (0xb543d088 libxul.so+0xd26088)
   mozilla::ThebesLayerData::CanOptimizeImageLayer(nsDisplayListBuilder*) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:1723 (0xb541661a libxul.so+0xcff61a)
   mozilla::ContainerState::PopThebesLayerData() /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:1911 (0xb5419b48 libxul.so+0xd02b48)
   nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::Length() const /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsTArray.h:368 (discriminator 1) (0xb541a1d8 libxul.so+0xd031d8)
   mozilla::ContainerState::GetChildrenBounds() /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:533 (0xb541b146 libxul.so+0xd04146)
   already_AddRefed<mozilla::layers::ContainerLayer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb543f4ba libxul.so+0xd284ba)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e5e698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e5f13c libxul.so+0xd0413c)
   already_AddRefed<mozilla::layers::ContainerLayer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e833d6 libxul.so+0xd283d6)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e5e698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e5f13c libxul.so+0xd0413c)
   nsDisplayOwnLayer::BuildLayer(nsDisplayListBuilder*, mozilla::layers::LayerManager*, mozilla::ContainerLayerParameters const&) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:3580 (0xb543cb10 libxul.so+0xd25b10)
   nsDisplaySubDocument::BuildLayer(nsDisplayListBuilder*, mozilla::layers::LayerManager*, mozilla::ContainerLayerParameters const&) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/nsDisplayList.cpp:3615 (0xb5441756 libxul.so+0xd2a756)
   already_AddRefed<mozilla::layers::Layer>::take() /local/mnt/workspace/tkundu/kk36t8th/out/target/product/msm8610/obj/objdir-gecko/dist/include/nsCOMPtr.h:186 (0xb5e5e698 libxul.so+0xd03698)
   mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder*, mozilla::layers::LayerManager*, nsIFrame*, nsDisplayItem*, nsDisplayList const&, mozilla::ContainerLayerParameters const&, gfx3DMatrix const*, unsigned int) /local/mnt/workspace/tkundu/kk36t8th/gecko/layout/base/FrameLayerBuilder.cpp:3384 (0xb5e5f13c libxul.so+0xd0413c)
Flags: needinfo?(sotaro.ikeda.g)
it seems like there are 3 leaks 1) FD leaks 2) ion growth > 40MB 3) b2g USS growth 76MB at timestamp  2014-07-16 15:09:35 in logs (see link in Comment 24). 

Important thing is that b2g is not releasing memory with |get-about-memory.py --minimize| command
I can also reproduce this with Only step 1 and step 3 from Comment 6. I can also see big growth (see Comment 25) just after 1 hour of running automation.
As per Comment 24, the stack trace which is leaking memory, is in layer tree creation phase (rendering phase, not Composition). So it should be possibility [1] or [2] of Comment 19.
I found the leak problem on tiled layer. It is not clear that this bug is caused only from the tiled layer problem. I am going to create a bug for it.
Flags: needinfo?(sotaro.ikeda.g)
Depends on: 1039883
(In reply to Sotaro Ikeda [:sotaro] from comment #28)
> I found the leak problem on tiled layer. It is not clear that this bug is
> caused only from the tiled layer problem. I am going to create a bug for it.

Thanks for your help.
@sotaro: If you feel bug 1039883 is blocking bug for this bug then please also mark bug 1039883 as CAF FC 2.0 blocker bug . This will help us to track it properly.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Tapas Kumar Kundu from comment #30)
> @sotaro: If you feel bug 1039883 is blocking bug for this bug then please
> also mark bug 1039883 as CAF FC 2.0 blocker bug . This will help us to track
> it properly.

Tapas, how can I set it to "CAF FC 2.0 blocker bug"? bug 1039883  is nominating to "v1.4+", because the problem also exist on b2g-v1.4.
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(tkundu)
(In reply to Sotaro Ikeda [:sotaro PTO July/25 - Aug/3] from comment #31)
> (In reply to Tapas Kumar Kundu from comment #30)
> > @sotaro: If you feel bug 1039883 is blocking bug for this bug then please
> > also mark bug 1039883 as CAF FC 2.0 blocker bug . This will help us to track
> > it properly.
> 
> Tapas, how can I set it to "CAF FC 2.0 blocker bug"? bug 1039883  is
> nominating to "v1.4+", because the problem also exist on b2g-v1.4.

Inder has did it for us in that bug :) .
Flags: needinfo?(tkundu)
I am seeing big improvement from patch in bug 1039883 Comment 11 . b2g is not killed by lmk even in 2 hours of test. 

I will run stability test for very long time (48 hours ) before confirming  bug 1039883 Comment 11 is fixing this memleak issue fully. 

Thanks to sotaro for tile layer memleak patch :)
Observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.029
Moz BuildID: 20140710000201
B2G Version: 2.0
Gecko Version: 32.0a2
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=2fb60c777d3f82d580cba249e5e01a167a01de39
Component: General → Graphics: Layers
Product: Firefox OS → Core
Whether graphics or not (looks like it is), making it Core/Graphics as the Firefox OS/General just gets lost.
Keywords: footprint, perf
Whiteboard: [caf priority: p1][CR 691739] → [caf priority: p1][CR 691739][MemShrink]
Summary: b2g leaks lots of anon_inode:sync_fence FD → potential b2g memory leak which is causing OOM killer to kill b2g.
Some of the leak reported here was fixed in bug 1039883.
We do have some more memory leaks remaining: e.g., Bug 1041751.
No solution needed in this bug so closing it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Not enough information on this bug to create a valid test case
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Not enough information on how we could do this repeatedly over a 24 hour period. No moztrap test case added.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Flags: in-moztrap-
Unable to verify due to insufficient access and resources.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][QAnalyst-verify-]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][QAnalyst-verify-] → [QAnalyst-Triage+][QAnalyst-verify-]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.