Closed Bug 1037360 Opened 6 years ago Closed 6 years ago

B2G process is leaking Vss allocation

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

()

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

People

(Reporter: tkundu, Assigned: sotaro)

References

Details

(4 keywords, Whiteboard: [b2g-crash][caf-crash 252][caf priority: p1][CR 690932][MemShrink][c=memory u=2.0 p= s=])

Attachments

(2 files, 9 obsolete files)

12.79 KB, patch
sotaro
: review+
bjacob
: review+
Details | Diff | Splinter Review
11.80 KB, patch
sotaro
: review+
Details | Diff | Splinter Review
STR:

Run this script on FFOS 2.0 build [6]:

Scripts (Pseudocode):

Open close an app
-----------------
from marionette import Marionette
import gaiatest
import time

m = Marionette("localhost", 2828)
m.start_session()
a = gaiatest.GaiaApps(m)

while True:
  print "Opening Phone"
  app = a.launch("phone")
  time.sleep(2)
  print "Closing Phone"
  a.kill(app)
  time.sleep(2)



We can see very quickly b2g process's Vss has reached 526324 KB from 253240 KB quickly.

Observation: (Consider timestamp 2014-07-11 06:52:36 and 2014-07-11 07:54:55 in attached logs)

1) ION allocation log does not leak over between these timestamps
2) Kgsl memory allocation log does not show leak between these timestamps.
3) b2g process USS number does not show leak between these timestamps.

4) 
   A) b2g_smap*.txt file shows b2g process has 1012KBx143 = ~143MB VSS from different thread stacks [1] [2] at timestamp 2014-07-11 06:52:36

   B) b2g_smap*.txt file shows b2g process has 1012KBx324 = ~324MB VSS from different thread stacks [1] [2] at timestamp 2014-07-11 07:54:55

   C) Difference is 324MB-143MB=181MB between (A) and (B). Total VSS increment is 526MB-319MB=206MB[3] which closes matches 181MB

5) 1012KB is mostly allocated from BufMgrParent#<number> thread [4]. We can also number of BufMgrParent#<number> thread is increasing over a period of time in top_*.log.txt log file.

[1] http://stackoverflow.com/questions/19379793/how-to-identify-stack-and-heap-segments-in-proc-pid-maps-file
[2] search for 1012 string in b2g_smap*.txt
[3] Compare Vss number for timestamp 2014-07-11 06:52:36 and 2014-07-11 07:54:55 in b2g-procrank log
[4] See thread id in b2g_smap*.txt and thread name in top_*.txt file. 


We can see BufMgrParen thread is created in gecko at [5] .

[5] http://dxr.mozilla.org/mozilla-central/search?q=BufMgrParent&case=false


Please v1.4 does not show this huge Vss increment over time for same STR. We confirmed it by running same script on both v1.4 and v2.0.

[6] gaia : https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gaia/commit/?h=mozilla/v2.0&id=d96dffda5a72906acd44840716d11bae6b2c7988
    gecko : https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gecko/commit/?h=mozilla/v2.0&id=acf3de0d846227c28de3ada229582018e80c5365


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




This is affecting device performance on 256MB configuration. We tested on msm8610 256MB device.
blocking-b2g: --- → 2.0?
Whiteboard: [CR 690932]
I think this is the same as bug 1036482.
See Also: → 1036482
Whiteboard: [CR 690932] → [caf priority: p2][CR 690932]
I don't think BufferManagerParent ever cleans itself up ...
Component: General → Graphics: Layers
Product: Firefox OS → Core
Whiteboard: [caf priority: p2][CR 690932] → [caf priority: p2][CR 690932][MemShrink]
Tapas, the problem exist even with Bug 1034294 fix?
Flags: needinfo?(tkundu)
(In reply to Sotaro Ikeda [:sotaro] from comment #3)
> Tapas, the problem exist even with Bug 1034294 fix?

Sorry, cancel the need-info. It fixes only ion related problem.
Flags: needinfo?(tkundu)
Sotaro, I don't think Bug 1034294 fixes the problem entirely.  As far as I can see (from reading code) we never delete the SharedBufferManagerParent.  Can you see if that destructor is ever invoked?
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> Sotaro, I don't think Bug 1034294 fixes the problem entirely.  As far as I
> can see (from reading code) we never delete the SharedBufferManagerParent. 
> Can you see if that destructor is ever invoked?

Yhea, I recognized it after wrote the comment 3. Okey, I am going to check it.
Flags: needinfo?(sotaro.ikeda.g)
I confirmed that SharedBufferManagerParent's destructor is not called, even when a related application is killed.
Assignee: nobody → sotaro.ikeda.g
I filed bug 1037154 which I believe is a different, but similar, problem. Lets keep an eye out on both since the root bug might be similar.
See Also: → 1037154
Status: NEW → ASSIGNED
By applying the patch, SharedBufferManagerParent becomes destructed on master flame.
(In reply to Sotaro Ikeda [:sotaro] from comment #9)
> Created attachment 8454605 [details] [diff] [review]
> patch - Fix SharedBufferManagerParent's destruction
> 
> By applying the patch, SharedBufferManagerParent becomes destructed on
> master flame.

Could you please give us a patch for FFOS v2.0. This is P1 blocker for us and we want to try your patch on v2.0 in our stability testing.
Flags: needinfo?(sotaro.ikeda.g)
Whiteboard: [caf priority: p2][CR 690932][MemShrink] → [CR 690932]
A patch for b2g-v2.0.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Tapas Kumar Kundu from comment #11)
> (In reply to Sotaro Ikeda [:sotaro] from comment #9)
> > Created attachment 8454605 [details] [diff] [review]
> > patch - Fix SharedBufferManagerParent's destruction
> > 
> > By applying the patch, SharedBufferManagerParent becomes destructed on
> > master flame.
> 
> Could you please give us a patch for FFOS v2.0. This is P1 blocker for us
> and we want to try your patch on v2.0 in our stability testing.

attachment 8454621 [details] [diff] [review] is a patch for latest FFOS v2.0.
Comment on attachment 8454605 [details] [diff] [review]
patch - Fix SharedBufferManagerParent's destruction

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

This is fine for testing, but I don't see why we need the refcounting here.  What's wrong with just sending runnable with an nsAutoPtr to 'this' to the even loop from ActorDestroy?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #14)
> Comment on attachment 8454605 [details] [diff] [review]
> patch - Fix SharedBufferManagerParent's destruction
> 
> Review of attachment 8454605 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is fine for testing, but I don't see why we need the refcounting here. 
> What's wrong with just sending runnable with an nsAutoPtr to 'this' to the
> even loop from ActorDestroy?

Thanks for the advice. It is just to use same code to ImageBridgeParent. Your suggestion is better way. I am going to update the patch.
Apply the comment.
Attachment #8454605 - Attachment is obsolete: true
Attachment #8454621 - Attachment is obsolete: true
Whiteboard: [CR 690932] → [caf priority: p2][CR 690932]
A patch for b2g-v2.0.
Whiteboard: [caf priority: p2][CR 690932] → [caf priority: p2][CR 690932][MemShrink]
(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> Created attachment 8454683 [details] [diff] [review]
> patch ver 2 for b2g-v2.0 - Fix SharedBufferManagerParent's destruction
> 
> A patch for b2g-v2.0.

I am seeing following stack trace with STR from Comment 0

===================
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 269.877]
0xb4dbcf52 in mozilla::layers::SharedBufferManagerParent::DropGrallocBuffer (this=this@entry=0x0, aDesc=...) at ../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp:254
254	../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp: No such file or directory.
(gdb) bt
#0  0xb4dbcf52 in mozilla::layers::SharedBufferManagerParent::DropGrallocBuffer (this=this@entry=0x0, aDesc=...) at ../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp:254
#1  0xb4dc1156 in DeallocateSharedData (this=0xa866ef40) at ../../../../../../../../gecko/gfx/layers/opengl/GrallocTextureHost.cpp:381
#2  mozilla::layers::GrallocTextureHostOGL::DeallocateSharedData (this=0xa866ef40) at ../../../../../../../../gecko/gfx/layers/opengl/GrallocTextureHost.cpp:365
#3  0xb4db0a60 in mozilla::layers::TextureHost::Finalize (this=this@entry=0xa866ef40) at ../../../../../../../../gecko/gfx/layers/composite/TextureHost.cpp:269
#4  0xb4dadac8 in Release (this=0xa866ef44) at ../../dist/include/mozilla/layers/AtomicRefCountedWithFinalize.h:45
#5  mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureHost>::Release (this=0xa866ef44) at ../../dist/include/mozilla/layers/AtomicRefCountedWithFinalize.h:31
#6  0xb4db119a in unref (t=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:281
#7  mozilla::RefPtr<mozilla::layers::TextureHost>::assign (this=0xaccfabd4, t=0x0) at ../../dist/include/mozilla/RefPtr.h:267
#8  0xb4b8f9ec in mozilla::dom::asmjscache::PAsmJSCacheEntryChild::DestroySubtree (this=0xaccfabb0, why=why@entry=mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::AbnormalShutdown) at PAsmJSCacheEntryParent.cpp:420
#9  0xb4c0014a in mozilla::layers::PLayerTransactionParent::DestroySubtree (this=0xac3db920, why=why@entry=mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::AbnormalShutdown) at PLayerTransactionParent.cpp:987
#10 0xb4ba89bc in mozilla::layers::PCompositorParent::DestroySubtree (this=this@entry=0xb67b0460, why=why@entry=mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::AbnormalShutdown) at PCompositorParent.cpp:1048
#11 0xb4babc4a in mozilla::layers::PCompositorParent::OnChannelError (this=0xb67b0460) at PCompositorParent.cpp:934
#12 0xb4b89658 in mozilla::ipc::MessageChannel::NotifyMaybeChannelError (this=this@entry=0xb67b0490) at ../../../../../../../../gecko/ipc/glue/MessageChannel.cpp:1557
#13 0xb4b89796 in mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError (this=0xb67b0490) at ../../../../../../../../gecko/ipc/glue/MessageChannel.cpp:1586
#14 0xb4a2b52c in DispatchToMethod<FdWatcher, void (FdWatcher::*)()> (method=(void (FdWatcher::*)(FdWatcher * const)) 0xb4b89739 <mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError()>, obj=<optimized out>, arg=...)
    at ../../../../../../../../gecko/ipc/chromium/src/base/tuple.h:383
#15 RunnableMethod<FdWatcher, void (FdWatcher::*)(), Tuple0>::Run (this=<optimized out>) at ../../../../../../../../gecko/ipc/chromium/src/base/task.h:307
#16 0xb4b7f778 in MessageLoop::RunTask (this=0xadb01cb0, task=0xac3cad60) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:357
#17 0xb4b7fe32 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:365
#18 0xb4b80e64 in DoWork (this=<optimized out>) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:443
#19 MessageLoop::DoWork (this=0xadb01cb0) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:422
#20 0xb4b80ff4 in base::MessagePumpDefault::Run (this=0xb2cea460, delegate=0xadb01cb0) at ../../../../../../../../gecko/ipc/chromium/src/base/message_pump_default.cc:34
#21 0xb4b7f706 in MessageLoop::RunInternal (this=this@entry=0xadb01cb0) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:229
#22 0xb4b7f7b8 in RunHandler (this=0xadb01cb0) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:222
#23 MessageLoop::Run (this=this@entry=0xadb01cb0) at ../../../../../../../../gecko/ipc/chromium/src/base/message_loop.cc:196
#24 0xb4b8224c in base::Thread::ThreadMain (this=0xb2ce9940) at ../../../../../../../../gecko/ipc/chromium/src/base/thread.cc:168
#25 0xb4b78848 in ThreadFunc (closure=<optimized out>) at ../../../../../../../../gecko/ipc/chromium/src/base/platform_thread_posix.cc:39
#26 0xb6f3a22c in __thread_entry (func=0xb4b78841 <ThreadFunc(void*)>, arg=0xb2ce9940, tls=0xadb01dd0) at bionic/libc/bionic/pthread_create.cpp:105
#27 0xb6f3a3c4 in pthread_create (thread_out=0xb2ce9948, attr=<optimized out>, start_routine=0xb4b78841 <ThreadFunc(void*)>, arg=0x78) at bionic/libc/bionic/pthread_create.cpp:224
#28 0xb0aa9ffc in ?? ()
================
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Sotaro Ikeda [:sotaro] from comment #17)
> Created attachment 8454683 [details] [diff] [review]
> patch ver 2 for b2g-v2.0 - Fix SharedBufferManagerParent's destruction
> 
> A patch for b2g-v2.0.

I think there is a race condition in this line:

XRE_GetIOMessageLoop()->PostTask(FROM_HERE, task);

and that's the reason of the crash in comment #19. You post a task on the IPC thread instead of the thread where BufferManagerParent runs. It should be MessageLoop::current()->PostTask(FROM_HERE, task);
(In reply to Tapas Kumar Kundu from comment #19)
> (In reply to Sotaro Ikeda [:sotaro] from comment #17)
> > Created attachment 8454683 [details] [diff] [review]
> > patch ver 2 for b2g-v2.0 - Fix SharedBufferManagerParent's destruction
> > 
> > A patch for b2g-v2.0.
> 
> I am seeing following stack trace with STR from Comment 0
> 
> ===================
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 269.877]
> 0xb4dbcf52 in mozilla::layers::SharedBufferManagerParent::DropGrallocBuffer
> (this=this@entry=0x0, aDesc=...) at
> ../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp:
> 254
> 254
> ../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp:
> No such file or directory.
> (gdb) bt
> #0  0xb4dbcf52 in
> mozilla::layers::SharedBufferManagerParent::DropGrallocBuffer
> (this=this@entry=0x0, aDesc=...) at
> ../../../../../../../../gecko/gfx/layers/ipc/SharedBufferManagerParent.cpp:
> 254
> #1  0xb4dc1156 in DeallocateSharedData (this=0xa866ef40) at
> ../../../../../../../../gecko/gfx/layers/opengl/GrallocTextureHost.cpp:381
> #2  mozilla::layers::GrallocTextureHostOGL::DeallocateSharedData
> (this=0xa866ef40) at

Thanks for reporting. The crash is caused by that some code does not care about the shutdown.
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8454683 - Attachment is obsolete: true
If we want to handle the race condition correctly between GrallocTextureHostOGL and SharedBufferManagerParent, SharedBufferManagerParent might need to be reference counted.
(In reply to Sotaro Ikeda [:sotaro] from comment #22)
> If we want to handle the race condition correctly between
> GrallocTextureHostOGL and SharedBufferManagerParent,
> SharedBufferManagerParent might need to be reference counted.

Or, change SharedBufferManagerParent::DropGrallocBuffer() to static function and handle the operation as atomic.
Fix shutdown race condition problem.
Attachment #8454678 - Attachment is obsolete: true
Fix nits.
Attachment #8455388 - Attachment is obsolete: true
Add comments.
Attachment #8455392 - Attachment is obsolete: true
A patch for b2g v2.0.
Tapas -- please try out the latest patch.
Flags: needinfo?(tkundu)
Attachment #8455424 - Flags: review?(nical.bugzilla)
Comment on attachment 8455424 [details] [diff] [review]
patch for b2g-v2.0 - Fix SharedBufferManagerParent's destruction

Change the review request to  jrmuizel. This is bug is very heavy blocker of b2g v2.0.
Attachment #8455424 - Flags: review?(nical.bugzilla) → review?(jmuizelaar)
Need to un-bitrot master patch based on Bug 1036419 commit.
Depends on: 1036419
Comment on attachment 8455424 [details] [diff] [review]
patch for b2g-v2.0 - Fix SharedBufferManagerParent's destruction

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

::: gfx/layers/ipc/SharedBufferManagerParent.cpp
@@ +83,5 @@
> +        : mSharedBufferManager(aSharedBufferManager) {
> +    }
> +    virtual void Run() MOZ_OVERRIDE {}
> +private:
> +    nsAutoPtr<SharedBufferManagerParent> mSharedBufferManager;

Can you use UniquePtr here instead of nsAutoPtr and make the DeleteSharedBufferManagerParentTask take a UniquePtr as well?
Attachment #8455424 - Flags: review?(jmuizelaar) → review+
(In reply to Jeff Muizelaar [:jrmuizel] from comment #32)
> Comment on attachment 8455424 [details] [diff] [review]
> patch ver 5 for b2g-v2.0 - Fix SharedBufferManagerParent's destruction
> 
> Review of attachment 8455424 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/layers/ipc/SharedBufferManagerParent.cpp
> @@ +83,5 @@
> > +        : mSharedBufferManager(aSharedBufferManager) {
> > +    }
> > +    virtual void Run() MOZ_OVERRIDE {}
> > +private:
> > +    nsAutoPtr<SharedBufferManagerParent> mSharedBufferManager;
> 
> Can you use UniquePtr here instead of nsAutoPtr and make the
> DeleteSharedBufferManagerParentTask take a UniquePtr as well?

I am seeing b2g process is quited with this patch. I am trying to collect stack trace for it. @Sotaro , Could you please run automation from #comment 0 before uploading fix for this bug. Please make sure that you are running automation for 3-4 hours. This should catch any corner cases.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Tapas Kumar Kundu from comment #33)
> 
> I am seeing b2g process is quited with this patch. I am trying to collect
> stack trace for it. @Sotaro , Could you please run automation from #comment
> 0 before uploading fix for this bug. Please make sure that you are running
> automation for 3-4 hours. This should catch any corner cases.

I just started the automation test from comment 0.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Sotaro Ikeda [:sotaro] from comment #34)
> (In reply to Tapas Kumar Kundu from comment #33)
> > 
> > I am seeing b2g process is quited with this patch. I am trying to collect
> > stack trace for it. @Sotaro , Could you please run automation from #comment
> > 0 before uploading fix for this bug. Please make sure that you are running
> > automation for 3-4 hours. This should catch any corner cases.
> 
> I just started the automation test from comment 0.

I still did not see the crash with v2.0 flame with full RAM config.
Tapas, can you provide the crash log when the stacktrace is collected?
Flags: needinfo?(tkundu)
Blocks: 1038854
I am also testing on 273MB flame, I still do not faced b2g process exit problem until now. Instaed Bug 1038854 happened intermittently. Bug 1038854 seems a different problem.
Jeff, can you check if UniquePtr usage is correct.
Attachment #8456361 - Flags: review?(jmuizelaar)
Attachment #8456361 - Flags: review?(jmuizelaar) → review+
Attachment #8455394 - Attachment is obsolete: true
Attachment #8455424 - Attachment description: patch ver 5 for b2g-v2.0 - Fix SharedBufferManagerParent's destruction → patch for b2g-v2.0 - Fix SharedBufferManagerParent's destruction
Attachment #8456361 - Attachment description: patch ver 6 - Fix SharedBufferManagerParent's destruction → patch - Fix SharedBufferManagerParent's destruction
(In reply to Sotaro Ikeda [:sotaro] from comment #38)
> Created attachment 8456361 [details] [diff] [review]
> patch - Fix SharedBufferManagerParent's destruction
> 
> Jeff, can you check if UniquePtr usage is correct.

UniquePtr can be used since gecko 33. Therefore the UniquePtr change do not need to uplift to a patch for b2g-v2.0.
(In reply to Sotaro Ikeda [:sotaro] from comment #36)
> Tapas, can you provide the crash log when the stacktrace is collected?

Hi Sotaro, 

I tried multiple times . But unfortunately , I am not hitting that b2g-crash anymore for same patch and same gaia/gecko. You may want to land this fix (if you are fine with it) and follow up with bug 1038854 .
Flags: needinfo?(tkundu)
Hi Tapas, thanks for testing. Today, I also do testing long time, but did not hit the crash. I am going to land the fix.
:nical, another one to save time with the timezones - can you take a look when you come in?
Flags: needinfo?(nical.bugzilla)
Top level actors must be deleted on the main thread (since nuwa landed)
Flags: needinfo?(nical.bugzilla)
(In reply to Nicolas Silva [:nical] from comment #45)
> Top level actors must be deleted on the main thread (since nuwa landed)

Thanks!
Flags: needinfo?(sotaro.ikeda.g)
Change to destruct SharedBufferMangeerParent in main thread.
Attachment #8456361 - Attachment is obsolete: true
Change to destruct SharedBufferManagerParent in Main thread. Carry, " jrmuizel".
Attachment #8455424 - Attachment is obsolete: true
Attachment #8456874 - Flags: review+
Comment on attachment 8456873 [details] [diff] [review]
patch - Fix SharedBufferManagerParent's destruction

Carry " r=jrmuizel".
Attachment #8456873 - Flags: review+
Comment on attachment 8456873 [details] [diff] [review]
patch - Fix SharedBufferManagerParent's destruction

bjacob, can you review the patch if the patch does not have a problem from IPC shutdown point of view?
Attachment #8456873 - Flags: review?(bjacob)
Attachment #8456873 - Flags: review?(bjacob) → review+
Keywords: perf
Whiteboard: [caf priority: p2][CR 690932][MemShrink] → [caf priority: p2][CR 690932][MemShrink][c=memory u= p= s=2.0]
Whiteboard: [caf priority: p2][CR 690932][MemShrink][c=memory u= p= s=2.0] → [caf priority: p2][CR 690932][MemShrink][c=memory u=2.0 p= s=]
Whiteboard: [caf priority: p2][CR 690932][MemShrink][c=memory u=2.0 p= s=] → [caf priority: p1][CR 690932][MemShrink][c=memory u=2.0 p= s=]
(In reply to Sotaro Ikeda [:sotaro] from comment #50)
>  https://tbpl.mozilla.org/?tree=Try&rev=7f21149b830d

The result seems good.
https://hg.mozilla.org/mozilla-central/rev/44dd7343b2c1
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
This may have unblocked GGC on B2G (bug 1020751); testing now.
Duplicate of this bug: 1036482
Whiteboard: [caf priority: p1][CR 690932][MemShrink][c=memory u=2.0 p= s=] → [b2g-crash][caf-crash 252][caf priority: p1][CR 690932][MemShrink][c=memory u=2.0 p= s=]
Keywords: crash
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
If we're seeing this again we need a new about:memory report (and ideally a new bug).
Flags: needinfo?(ggrisco)
Sorry for the spam, comment 58 is fallout from a cafbot bug that just got fixed.  AU 29 is quite old.
Flags: needinfo?(ggrisco)
Flags: in-moztrap?(bzumwalt)
No STR is present to create test case to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(bzumwalt)
Flags: in-moztrap-
Observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.079
Moz BuildID: 20140902000202
B2G Version: 2.0
Gecko Version: 32.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=449d8db9b3ea1f9262db822c37ef2143477172b7
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=3961e764e2c217a24954ed9d01b6caf67ab0a6e4
Observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.086
Moz BuildID: 20140909000202
B2G Version: 2.0
Gecko Version: 32.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=59a670d40ad7f5966ec7fafcab0f05009bea97ab
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=fa595608fbed514dd1dde393fdd46ef934df31a0
Not acting on this at this time; see comment 59.
Observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.088
Moz BuildID: 20140911000231
B2G Version: 2.0
Gecko Version: 32.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=ddec117b2d6ac8ea50d7fd833a9cf0605d5b358b
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=ef26d06076dd8909d82a1c0e1c2f501bc89b5161
Unable to verify due to automation STR.
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.