[dolphin] when monkey test running several hours,the screen fixed,Physical key invalid and Computer does not recognize the device

NEW
Unassigned

Status

Firefox OS
Performance
3 years ago
2 years ago

People

(Reporter: ben.song, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:-, tracking-b2g:-)

Details

(Whiteboard: [sprd354080])

Attachments

(4 attachments)

(Reporter)

Description

3 years ago
Created attachment 8487777 [details]
kernel-log2.zip

Hi GaryChen,

   In recent monkey test,this problem has be reproduced,and I find some log in main log:
08-18 08:01:17.740   803   835 D gralloc.scx15: alloc_device_alloc w:2916, h:3888, format:1 usage:0x133 start
08-18 08:01:18.230   803   835 D gralloc.scx15: the flag 0x4 and the vadress is 0xa4ec0000 and the size is 0x2b3fb00
08-18 08:01:18.300   803   835 D gralloc.scx15: alloc_device_alloc handle:0xa8602220 end err is 0
08-18 08:01:18.500   803   835 D gralloc.scx15: alloc_device_alloc w:2916, h:3888, format:1 usage:0x133 start
08-18 08:01:22.300 12687 12691 I GonkMemoryPressure: Checking to see if memory pressure is over.
08-18 08:01:22.320   803   822 I GonkMemoryPressure: Checking to see if memory pressure is over.
08-18 08:01:22.320   803   822 I GonkMemoryPressure: Memory pressure is over.
08-18 08:01:22.320 12687 12691 I GonkMemoryPressure: Memory pressure is over.

   And I want to know which operation would allocate the memory of w:2916, h:3888 for I could not find the place,thanks.
(Reporter)

Comment 1

3 years ago
Created attachment 8487780 [details]
main-log2.zip
Flags: needinfo?(pcheng)
Flags: needinfo?(pcheng)
Whiteboard: [sprd328243]
(Reporter)

Comment 2

3 years ago
Created attachment 8487793 [details]
first_time_appear_main_log.zip
(Reporter)

Comment 3

3 years ago
Created attachment 8487794 [details]
first_time_appear_kernel_log.zip
(Reporter)

Comment 4

3 years ago
[Blocking Requested - why for this release]:
blocking-b2g: --- → 1.4?

Updated

3 years ago
blocking-b2g: 1.4? → -
(Reporter)

Updated

3 years ago
Summary: when monkey test running several hours,the screen fixed,Physical key invalid and Computer does not recognize the device → [dolphin] when monkey test running several hours,the screen fixed,Physical key invalid and Computer does not recognize the device
(Reporter)

Comment 5

3 years ago
Such as the title,after several hours monkey test,phone can't use adb shell to connect computer.As my analysis,this crash mostly happens at the moment of opening big memory consuming when it has been memory pressure.
About it's log,I find a common place,"alloc_device_alloc w:2916, h:3888",but I can't find which app allocate this piece of memory.Is B2G process or linux process ?
Thanks.
Flags: needinfo?(dliang)
Flags: needinfo?(alive)
(Reporter)

Updated

3 years ago
Whiteboard: [sprd328243] → [sprd354080]
Why do you needinfo me? Why is this put in WinMgmt?
Flags: needinfo?(alive)
(Reporter)

Comment 7

3 years ago
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> Why do you needinfo me? Why is this put in WinMgmt?

Dear Alive,

   Sorry,because base on the log I can't confirm which problem this bug belong to.So I want someone help me to find the origin of it.
Component: Gaia::System::Window Mgmt → Performance
(In reply to ben.song from comment #5)
> Such as the title,after several hours monkey test,phone can't use adb shell
> to connect computer.As my analysis,this crash mostly happens at the moment
> of opening big memory consuming when it has been memory pressure.
> About it's log,I find a common place,"alloc_device_alloc w:2916, h:3888",but
> I can't find which app allocate this piece of memory.Is B2G process or linux
> process ?
> Thanks.

Hi Ben,
Per my comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1041853#c43, please answer below 2 questions.

1. Why oom was triggered when free memory is enough?
2. By kernel log, it showed kernel is alive till 08-20 12:01:03 but no log from 08-18 11:09:02 to 08-20 12:00:56. I also found some call stack might be related to adbd, could you have member to check if it's normal? ---- (Question 2)

By my analysis, big size memory allocation caused application was killed by OOM/LMK. After killed, system should be stable. In kernel log, system is alive till 08-20 12:01:03, so I suspected there are other kernel related problems to cause system hang. Please try to provide analysis result of available sysdump. If possiable, please setup jtag debug environment and run the test.
Flags: needinfo?(dliang) → needinfo?(ben.song)
(Reporter)

Comment 9

3 years ago
(In reply to Danny Liang [:dliang] from comment #8)
> (In reply to ben.song from comment #5)
> > Such as the title,after several hours monkey test,phone can't use adb shell
> > to connect computer.As my analysis,this crash mostly happens at the moment
> > of opening big memory consuming when it has been memory pressure.
> > About it's log,I find a common place,"alloc_device_alloc w:2916, h:3888",but
> > I can't find which app allocate this piece of memory.Is B2G process or linux
> > process ?
> > Thanks.
> 
> Hi Ben,
> Per my comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1041853#c43,
> please answer below 2 questions.
> 
> 1. Why oom was triggered when free memory is enough?
> 2. By kernel log, it showed kernel is alive till 08-20 12:01:03 but no log
> from 08-18 11:09:02 to 08-20 12:00:56. I also found some call stack might be
> related to adbd, could you have member to check if it's normal? ----
> (Question 2)
> 
> By my analysis, big size memory allocation caused application was killed by
> OOM/LMK. After killed, system should be stable. In kernel log, system is
> alive till 08-20 12:01:03, so I suspected there are other kernel related
> problems to cause system hang. Please try to provide analysis result of
> available sysdump. If possiable, please setup jtag debug environment and run
> the test.

Hi Danny,

   OK,I would continue to analysis the sysdump of the log.And my colleague would check adbd process.
Flags: needinfo?(ben.song)

Comment 10

3 years ago
yanbin, can you help, can be with ben
Flags: needinfo?(yanbin.fang)
(Reporter)

Comment 11

3 years ago
(In reply to ben.song from comment #9)
> (In reply to Danny Liang [:dliang] from comment #8)
> > (In reply to ben.song from comment #5)
> > > Such as the title,after several hours monkey test,phone can't use adb shell
> > > to connect computer.As my analysis,this crash mostly happens at the moment
> > > of opening big memory consuming when it has been memory pressure.
> > > About it's log,I find a common place,"alloc_device_alloc w:2916, h:3888",but
> > > I can't find which app allocate this piece of memory.Is B2G process or linux
> > > process ?
> > > Thanks.
> > 
> > Hi Ben,
> > Per my comment in https://bugzilla.mozilla.org/show_bug.cgi?id=1041853#c43,
> > please answer below 2 questions.
> > 
> > 1. Why oom was triggered when free memory is enough?
> > 2. By kernel log, it showed kernel is alive till 08-20 12:01:03 but no log
> > from 08-18 11:09:02 to 08-20 12:00:56. I also found some call stack might be
> > related to adbd, could you have member to check if it's normal? ----
> > (Question 2)
> > 
> > By my analysis, big size memory allocation caused application was killed by
> > OOM/LMK. After killed, system should be stable. In kernel log, system is
> > alive till 08-20 12:01:03, so I suspected there are other kernel related
> > problems to cause system hang. Please try to provide analysis result of
> > available sysdump. If possiable, please setup jtag debug environment and run
> > the test.
> 
> Hi Danny,
> 
>    OK,I would continue to analysis the sysdump of the log.And my colleague
> would check adbd process.

Dear Danny,

Base on my analysis,I find adbd has no problem and I don't know why no log from 08-18 11:09:02 to 08-20 12:00:56.But I find allcation of a piece memory of 2916*3888 could bring big pressure to kernel.
About this piece memory,we find the route to reproduce it:
1.Open gallery app or camera app.(must have many picture in it)
2.Open the preview of first picture.
3.Slide picture to the preview of next picture quickly and constantly. 

About above reproduce i have several question:
1.We don't know whether the piece memory be fine.
2.if it is fine,can we avoid allcating the piece memory like that ?Because at the moment of low memory,this piece memory would bring crash of some app or system probably.
Flags: needinfo?(dliang)
(Reporter)

Comment 12

3 years ago
After we analysis this piece of memory use gdb,we get call stack of b2g and gallery.

call back of b2g process

Breakpoint 1, alloc_device_alloc (dev=0xb6a02550, w=2916, h=3888, format=1, usage=307, pHandle=0xb1726f44, pStride=0xb1726f30)
    at vendor/sprd/open-source/libs/gralloc/alloc_device.cpp:494
494	{
(gdb) bt
#0  alloc_device_alloc (dev=0xb6a02550, w=2916, h=3888, format=1, usage=307, pHandle=0xb1726f44, pStride=0xb1726f30)
    at vendor/sprd/open-source/libs/gralloc/alloc_device.cpp:494
#1  0xb6e5a1c0 in android::GraphicBufferAllocator::alloc (this=<optimized out>, w=w@entry=2916, h=h@entry=3888, 
    format=format@entry=1, usage=usage@entry=307, handle=handle@entry=0xb1726f44, stride=stride@entry=0xb1726f30)
    at frameworks/native/libs/ui/GraphicBufferAllocator.cpp:105
#2  0xb6e59a52 in android::GraphicBuffer::initSize (this=this@entry=0xb1726f00, w=w@entry=2916, h=h@entry=3888, 
    format=format@entry=1, reqUsage=reqUsage@entry=307) at frameworks/native/libs/ui/GraphicBuffer.cpp:146
#3  0xb6e59d68 in android::GraphicBuffer::GraphicBuffer (this=0xb1726f00, w=2916, h=3888, reqFormat=1, reqUsage=307)
    at frameworks/native/libs/ui/GraphicBuffer.cpp:59
#4  0xb50a09c4 in mozilla::layers::GrallocBufferActor::Create (aSize=..., aFormat=<optimized out>, aUsage=<optimized out>, 
    aOutHandle=0xad1ffa74) at ../../../gecko/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp:298
#5  0xb4f25f8c in mozilla::layers::PLayerTransactionParent::OnMessageReceived (this=0xaf8fd2a0, __msg=..., __reply=@0xad1ffb90: 0x0)
    at PLayerTransactionParent.cpp:693
#6  0xb4ed9e06 in mozilla::layers::PCompositorParent::OnMessageReceived (this=0xaa0106a0, __msg=..., __reply=@0xad1ffb90: 0x0)
    at PCompositorParent.cpp:474
#7  0xb4eb5a50 in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=0xaa0106d0, aMsg=...)
    at ../../../gecko/ipc/glue/MessageChannel.cpp:1067
#8  0xb4eb7862 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=<optimized out>)
    at ../../../gecko/ipc/glue/MessageChannel.cpp:1039
#9  0xb4eb54b4 in DispatchToMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)()> (
    method=(void (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0xb4eb77eb <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, arg=...) at ../../../gecko/ipc/chromium/src/base/tuple.h:383
#10 RunnableMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)(), Tuple0>::Run (this=<optimized out>)
    at ../../../gecko/ipc/chromium/src/base/task.h:307
#11 0xb4eb52ae in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:383
#12 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:400
#13 0xb4ead018 in MessageLoop::RunTask (this=0xad1ffcb0, task=0xa9d3f318)
    at ../../../gecko/ipc/chromium/src/base/message_loop.cc:344
#14 0xb4ead6da in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...)
    at ../../../gecko/ipc/chromium/src/base/message_loop.cc:352
#15 0xb4eae70c in DoWork (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:430
#16 MessageLoop::DoWork (this=0xad1ffcb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:409
#17 0xb4eae89c in base::MessagePumpDefault::Run (this=0xb276d2a0, delegate=0xad1ffcb0)
    at ../../../gecko/ipc/chromium/src/base/message_pump_default.cc:34
#18 0xb4eacfa6 in MessageLoop::RunInternal (this=this@entry=0xad1ffcb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#19 0xb4ead058 in RunHandler (this=0xad1ffcb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#20 MessageLoop::Run (this=this@entry=0xad1ffcb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#21 0xb4eaf84a in base::Thread::ThreadMain (this=0xae09eeb0) at ../../../gecko/ipc/chromium/src/base/thread.cc:162
#22 0xb4ea64fc in ThreadFunc (closure=<optimized out>) at ../../../gecko/ipc/chromium/src/base/platform_thread_posix.cc:39
#23 0xb6e8a21c in __thread_entry (func=0xb4ea64f5 <ThreadFunc(void*)>, arg=0xae09eeb0, tls=0xad1ffdd0)
    at bionic/libc/bionic/pthread_create.cpp:105
#24 0xb6e8a3b8 in pthread_create (thread_out=0xae09eeb8, attr=<optimized out>, start_routine=0xb4ea64f5 <ThreadFunc(void*)>, 
    arg=0x78) at bionic/libc/bionic/pthread_create.cpp:224
#25 0x00000000 in ?? ()
(Reporter)

Comment 13

3 years ago
call back of gallery process:

#0  __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:39
#1  0xb6ef7f58 in __pthread_cond_timedwait_relative (cond=cond@entry=0xb40b4d34, mutex=mutex@entry=0xb40caec0, reltime=0x0)
    at bionic/libc/bionic/pthread.c:1117
#2  0xb6ef7fb8 in __pthread_cond_timedwait (cond=0xb40b4d34, mutex=0xb40caec0, abstime=<optimized out>, clock=<optimized out>)
    at bionic/libc/bionic/pthread.c:1140
#3  0xb6f5edb4 in __wrap_pthread_cond_wait (cond=0xb40b4d34, mtx=0xb40caec0) at ../../../gecko/mozglue/build/Nuwa.cpp:1011
#4  0xb534cd98 in PR_WaitCondVar (cvar=0xb40b4d30, timeout=4294967295) at ../../../../../gecko/nsprpub/pr/src/pthreads/ptsynch.c:385
#5  0xb581017c in mozilla::CondVar::Wait (this=<optimized out>, interval=interval@entry=4294967295)
    at ../../dist/include/mozilla/CondVar.h:70
#6  0xb581472c in Wait (interval=4294967295, this=<optimized out>) at ../../dist/include/mozilla/Monitor.h:47
#7  mozilla::ipc::MessageChannel::WaitForSyncNotify (this=this@entry=0xb3f0eff0) at ../../../gecko/ipc/glue/MessageChannel.cpp:1340
#8  0xb5815f50 in mozilla::ipc::MessageChannel::SendAndWait (this=this@entry=0xb3f0eff0, aMsg=aMsg@entry=0xb1eb83a0, 
    aReply=aReply@entry=0xbebae164) at ../../../gecko/ipc/glue/MessageChannel.cpp:664
#9  0xb58165aa in mozilla::ipc::MessageChannel::Send (this=0xb3f0eff0, aMsg=aMsg@entry=0xb1eb83a0, aReply=aReply@entry=0xbebae164)
    at ../../../gecko/ipc/glue/MessageChannel.cpp:577
#10 0xb5880388 in mozilla::layers::PLayerTransactionChild::SendPGrallocBufferConstructor (this=this@entry=0xb385ec10, actor=
    0x610074, size=..., format=@0xbebae1d4: 1, usage=@0xbebae1d0: 307, handle=handle@entry=0xbebae1f8)
    at PLayerTransactionChild.cpp:132
#11 0xb588042e in mozilla::layers::PLayerTransactionChild::SendPGrallocBufferConstructor (this=0xb385ec10, size=..., 
    format=@0xbebae1d4: 1, usage=@0xbebae1d0: 307, handle=handle@entry=0xbebae1f8) at PLayerTransactionChild.cpp:92
#12 0xb59ff450 in mozilla::layers::ShadowLayerForwarder::AllocGrallocBuffer (this=<optimized out>, aSize=..., aFormat=1, 
    aUsage=307, aHandle=0xbebae1f8) at ../../../gecko/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp:419
#13 0xb5a39a98 in mozilla::layers::GrallocTextureClientOGL::AllocateGralloc (this=0xafe17470, aSize=..., aAndroidFormat=1, 
    aUsage=aUsage@entry=307) at ../../../gecko/gfx/layers/opengl/GrallocTextureClient.cpp:380
#14 0xb5a39bc8 in mozilla::layers::GrallocTextureClientOGL::AllocateForSurface (this=<optimized out>, aSize=...)
    at ../../../gecko/gfx/layers/opengl/GrallocTextureClient.cpp:325
#15 0xb5a144da in mozilla::layers::ContentClientRemoteBuffer::CreateAndAllocateTextureClient (this=this@entry=0xb0aeb5c0, 
    aClient=..., aFlags=aFlags@entry=16384) at ../../../gecko/gfx/layers/client/ContentClient.cpp:179
#16 0xb5a146ae in mozilla::layers::ContentClientRemoteBuffer::BuildTextureClients (this=this@entry=0xb0aeb5c0, 
    aFormat=<optimized out>, aRect=..., aFlags=aFlags@entry=0) at ../../../gecko/gfx/layers/client/ContentClient.cpp:219
#17 0xb5a1472a in mozilla::layers::ContentClientRemoteBuffer::CreateBuffer (this=0xb0aeb5c0, aType=COLOR_ALPHA, aRect=..., 
    aFlags=0, aBlackDT=0xbebae2f0, aWhiteDT=0xbebae2f4) at ../../../gecko/gfx/layers/client/ContentClient.cpp:244
#18 0xb5a0ae46 in mozilla::layers::RotatedContentBuffer::BeginPaint (this=0xb0aeb5d4, aLayer=0xb413b420, aFlags=1)
    at ../../../gecko/gfx/layers/RotatedBuffer.cpp:627
#19 0xb5a13654 in mozilla::layers::DeprecatedContentClientRemoteBuffer::BeginPaintBuffer (this=<optimized out>, 
    aLayer=<optimized out>, aFlags=<optimized out>) at ../../dist/include/mozilla/layers/ContentClient.h:329
#20 0xb5a121e6 in mozilla::layers::ClientThebesLayer::PaintThebes (this=this@entry=0xb413b420)
    at ../../../gecko/gfx/layers/client/ClientThebesLayer.cpp:56
#21 0xb5a12508 in mozilla::layers::ClientThebesLayer::RenderLayer (this=0xb413b420)
    at ../../../gecko/gfx/layers/client/ClientThebesLayer.cpp:104
#22 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb3879800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#23 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb387e800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#24 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb320f800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#25 0xb5a1179e in mozilla::layers::ClientLayerManager::EndTransactionInternal (this=this@entry=0xb3863440, 
    aCallback=aCallback@entry=
    0xb60203f9 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*)>, aCallbackData=aCallbackData@entry=0xbebae7a0)
    at ../../../gecko/gfx/layers/client/ClientLayerManager.cpp:198
#26 0xb5a11e74 in mozilla::layers::ClientLayerManager::EndTransaction (this=0xb3863440, 
---Type <return> to continue, or q <return> to quit---
    aCallback=0xb60203f9 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*)>, aCallbackData=0xbebae7a0, 
    aFlags=mozilla::layers::LayerManager::END_DEFAULT) at ../../../gecko/gfx/layers/client/ClientLayerManager.cpp:224
#27 0xb6044bd4 in nsDisplayList::PaintForFrame (this=this@entry=0xbebae784, aBuilder=aBuilder@entry=0xbebae7a0, 
    aCtx=aCtx@entry=0x0, aForFrame=<optimized out>, aFlags=aFlags@entry=13) at ../../../gecko/layout/base/nsDisplayList.cpp:1380
#28 0xb6044d70 in nsDisplayList::PaintRoot (this=this@entry=0xbebae784, aBuilder=aBuilder@entry=0xbebae7a0, aCtx=aCtx@entry=0x0, 
    aFlags=13) at ../../../gecko/layout/base/nsDisplayList.cpp:1221
#29 0xb604e732 in nsLayoutUtils::PaintFrame (aRenderingContext=aRenderingContext@entry=0x0, aFrame=aFrame@entry=0xb362d2b8, 
    aDirtyRegion=..., aBackstop=aBackstop@entry=0, aFlags=772) at ../../../gecko/layout/base/nsLayoutUtils.cpp:2687
#30 0xb6018652 in PresShell::Paint (this=0xb4067a20, aViewToPaint=<optimized out>, aDirtyRegion=..., aFlags=<optimized out>)
    at ../../../gecko/layout/base/nsPresShell.cpp:5932
#31 0xb5e07214 in nsViewManager::ProcessPendingUpdatesPaint (this=0xb38e0730, aWidget=aWidget@entry=0xb4154110)
    at ../../../gecko/view/src/nsViewManager.cpp:456
#32 0xb5e07354 in nsViewManager::ProcessPendingUpdatesForView (this=this@entry=0xb3f02e60, aView=<optimized out>, 
    aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at ../../../gecko/view/src/nsViewManager.cpp:397
#33 0xb5e073d6 in nsViewManager::ProcessPendingUpdates (this=this@entry=0xb38e0730)
    at ../../../gecko/view/src/nsViewManager.cpp:1088
#34 0xb601b892 in nsRefreshDriver::Tick (this=0xb3f02e60, aNowEpoch=<optimized out>, aNowTime=...)
    at ../../../gecko/layout/base/nsRefreshDriver.cpp:1207
#35 0xb601bc24 in TickDriver (now=..., jsnow=1411520224345858, driver=<optimized out>)
    at ../../../gecko/layout/base/nsRefreshDriver.cpp:168
#36 mozilla::RefreshDriverTimer::Tick (this=<optimized out>) at ../../../gecko/layout/base/nsRefreshDriver.cpp:160
#37 0xb56e2ed6 in nsTimerImpl::Fire (this=0xb3874940) at ../../../gecko/xpcom/threads/nsTimerImpl.cpp:562
#38 0xb56e2f92 in nsTimerEvent::Run (this=0xb38b4150) at ../../../gecko/xpcom/threads/nsTimerImpl.cpp:646
#39 0xb56e127e in ProcessNextEvent (result=0xbebaed97, mayWait=<optimized out>, this=0xb48025c0)
    at ../../../gecko/xpcom/threads/nsThread.cpp:694
#40 nsThread::ProcessNextEvent (this=0xb48025c0, mayWait=<optimized out>, result=0xbebaed97)
    at ../../../gecko/xpcom/threads/nsThread.cpp:618
#41 0xb56b4c2a in NS_ProcessNextEvent (thread=<optimized out>, mayWait=mayWait@entry=false)
    at ../../../gecko/xpcom/glue/nsThreadUtils.cpp:263
#42 0xb58175ec in mozilla::ipc::MessagePump::Run (this=0xb4801af0, aDelegate=0xbebaee98)
    at ../../../gecko/ipc/glue/MessagePump.cpp:95
#43 0xb580bfa6 in MessageLoop::RunInternal (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#44 0xb580c058 in RunHandler (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#45 MessageLoop::Run (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#46 0xb5c6749a in nsBaseAppShell::Run (this=0xb40d1ac0) at ../../../gecko/widget/xpwidgets/nsBaseAppShell.cpp:164
#47 0xb623a336 in XRE_RunAppShell () at ../../../gecko/toolkit/xre/nsEmbedFunctions.cpp:679
#48 0xb580bfa6 in MessageLoop::RunInternal (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#49 0xb580c058 in RunHandler (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#50 MessageLoop::Run (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#51 0xb623a6be in XRE_InitChildProcess (aArgc=6, aArgv=<optimized out>, aProcess=<optimized out>)
    at ../../../gecko/toolkit/xre/nsEmbedFunctions.cpp:516
#52 0x000086ee in main (argc=8, argv=0xbebaf824) at ../../../gecko/ipc/app/MozillaRuntimeMain.cpp:149
(gdb) frame 10
#10 0xb5880388 in mozilla::layers::PLayerTransactionChild::SendPGrallocBufferConstructor (this=this@entry=0xb385ec10, 
    actor=0x610074, size=..., format=@0xbebae1d4: 1, usage=@0xbebae1d0: 307, handle=handle@entry=0xbebae1f8)
    at PLayerTransactionChild.cpp:132
132	    bool __sendok = (mChannel)->Send(__msg, (&(__reply)));
(gdb) n
^C
Program received signal SIGINT, Interrupt.
__futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:39
39	    swi     #0
(gdb) bt
#0  __futex_syscall3 () at bionic/libc/arch-arm/bionic/futex_arm.S:39
#1  0xb6ef7f58 in __pthread_cond_timedwait_relative (cond=cond@entry=0xb40b4d34, mutex=mutex@entry=0xb40caec0, reltime=0x0)
    at bionic/libc/bionic/pthread.c:1117
#2  0xb6ef7fb8 in __pthread_cond_timedwait (cond=0xb40b4d34, mutex=0xb40caec0, abstime=<optimized out>, clock=<optimized out>)
    at bionic/libc/bionic/pthread.c:1140
#3  0xb6f5edb4 in __wrap_pthread_cond_wait (cond=0xb40b4d34, mtx=0xb40caec0) at ../../../gecko/mozglue/build/Nuwa.cpp:1011
#4  0xb534cd98 in PR_WaitCondVar (cvar=0xb40b4d30, timeout=4294967295) at ../../../../../gecko/nsprpub/pr/src/pthreads/ptsynch.c:385
#5  0xb581017c in mozilla::CondVar::Wait (this=<optimized out>, interval=interval@entry=4294967295)
    at ../../dist/include/mozilla/CondVar.h:70
#6  0xb581472c in Wait (interval=4294967295, this=<optimized out>) at ../../dist/include/mozilla/Monitor.h:47
#7  mozilla::ipc::MessageChannel::WaitForSyncNotify (this=this@entry=0xb3f0eff0) at ../../../gecko/ipc/glue/MessageChannel.cpp:1340
#8  0xb5815f50 in mozilla::ipc::MessageChannel::SendAndWait (this=this@entry=0xb3f0eff0, aMsg=aMsg@entry=0xb1eb83a0, 
    aReply=aReply@entry=0xbebae164) at ../../../gecko/ipc/glue/MessageChannel.cpp:664
#9  0xb58165aa in mozilla::ipc::MessageChannel::Send (this=0xb3f0eff0, aMsg=aMsg@entry=0xb1eb83a0, aReply=aReply@entry=0xbebae164)
    at ../../../gecko/ipc/glue/MessageChannel.cpp:577
#10 0xb5880388 in mozilla::layers::PLayerTransactionChild::SendPGrallocBufferConstructor (this=this@entry=0xb385ec10, 
    actor=0x610074, size=..., format=@0xbebae1d4: 1, usage=@0xbebae1d0: 307, handle=handle@entry=0xbebae1f8)
    at PLayerTransactionChild.cpp:132
#11 0xb588042e in mozilla::layers::PLayerTransactionChild::SendPGrallocBufferConstructor (this=0xb385ec10, size=..., 
    format=@0xbebae1d4: 1, usage=@0xbebae1d0: 307, handle=handle@entry=0xbebae1f8) at PLayerTransactionChild.cpp:92
#12 0xb59ff450 in mozilla::layers::ShadowLayerForwarder::AllocGrallocBuffer (this=<optimized out>, aSize=..., aFormat=1, 
    aUsage=307, aHandle=0xbebae1f8) at ../../../gecko/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp:419
#13 0xb5a39a98 in mozilla::layers::GrallocTextureClientOGL::AllocateGralloc (this=0xafe17470, aSize=..., aAndroidFormat=1, 
    aUsage=aUsage@entry=307) at ../../../gecko/gfx/layers/opengl/GrallocTextureClient.cpp:380
#14 0xb5a39bc8 in mozilla::layers::GrallocTextureClientOGL::AllocateForSurface (this=<optimized out>, aSize=...)
    at ../../../gecko/gfx/layers/opengl/GrallocTextureClient.cpp:325
#15 0xb5a144da in mozilla::layers::ContentClientRemoteBuffer::CreateAndAllocateTextureClient (this=this@entry=0xb0aeb5c0, 
    aClient=..., aFlags=aFlags@entry=16384) at ../../../gecko/gfx/layers/client/ContentClient.cpp:179
#16 0xb5a146ae in mozilla::layers::ContentClientRemoteBuffer::BuildTextureClients (this=this@entry=0xb0aeb5c0, 
    aFormat=<optimized out>, aRect=..., aFlags=aFlags@entry=0) at ../../../gecko/gfx/layers/client/ContentClient.cpp:219
#17 0xb5a1472a in mozilla::layers::ContentClientRemoteBuffer::CreateBuffer (this=0xb0aeb5c0, aType=COLOR_ALPHA, aRect=..., 
    aFlags=0, aBlackDT=0xbebae2f0, aWhiteDT=0xbebae2f4) at ../../../gecko/gfx/layers/client/ContentClient.cpp:244
#18 0xb5a0ae46 in mozilla::layers::RotatedContentBuffer::BeginPaint (this=0xb0aeb5d4, aLayer=0xb413b420, aFlags=1)
    at ../../../gecko/gfx/layers/RotatedBuffer.cpp:627
#19 0xb5a13654 in mozilla::layers::DeprecatedContentClientRemoteBuffer::BeginPaintBuffer (this=<optimized out>, 
    aLayer=<optimized out>, aFlags=<optimized out>) at ../../dist/include/mozilla/layers/ContentClient.h:329
#20 0xb5a121e6 in mozilla::layers::ClientThebesLayer::PaintThebes (this=this@entry=0xb413b420)
    at ../../../gecko/gfx/layers/client/ClientThebesLayer.cpp:56
#21 0xb5a12508 in mozilla::layers::ClientThebesLayer::RenderLayer (this=0xb413b420)
    at ../../../gecko/gfx/layers/client/ClientThebesLayer.cpp:104
#22 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb3879800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#23 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb387e800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#24 0xb5a110f6 in mozilla::layers::ClientContainerLayer::RenderLayer (this=0xb320f800)
    at ../../../gecko/gfx/layers/client/ClientContainerLayer.h:79
#25 0xb5a1179e in mozilla::layers::ClientLayerManager::EndTransactionInternal (this=this@entry=0xb3863440, 
    aCallback=aCallback@entry=0xb60203f9 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*)>, aCallbackData=aCallbackData@entry=0xbebae7a0)
    at ../../../gecko/gfx/layers/client/ClientLayerManager.cpp:198
#26 0xb5a11e74 in mozilla::layers::ClientLayerManager::EndTransaction (this=0xb3863440, 
    aCallback=0xb60203f9 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&,---Type <return> to continue, or q <return> to quit---
 mozilla::layers::DrawRegionClip, nsIntRegion const&, void*)>, aCallbackData=0xbebae7a0, 
    aFlags=mozilla::layers::LayerManager::END_DEFAULT) at ../../../gecko/gfx/layers/client/ClientLayerManager.cpp:224
#27 0xb6044bd4 in nsDisplayList::PaintForFrame (this=this@entry=0xbebae784, aBuilder=aBuilder@entry=0xbebae7a0, 
    aCtx=aCtx@entry=0x0, aForFrame=<optimized out>, aFlags=aFlags@entry=13) at ../../../gecko/layout/base/nsDisplayList.cpp:1380
#28 0xb6044d70 in nsDisplayList::PaintRoot (this=this@entry=0xbebae784, aBuilder=aBuilder@entry=0xbebae7a0, aCtx=aCtx@entry=0x0, 
    aFlags=13) at ../../../gecko/layout/base/nsDisplayList.cpp:1221
#29 0xb604e732 in nsLayoutUtils::PaintFrame (aRenderingContext=aRenderingContext@entry=0x0, aFrame=aFrame@entry=0xb362d2b8, 
    aDirtyRegion=..., aBackstop=aBackstop@entry=0, aFlags=772) at ../../../gecko/layout/base/nsLayoutUtils.cpp:2687
#30 0xb6018652 in PresShell::Paint (this=0xb4067a20, aViewToPaint=<optimized out>, aDirtyRegion=..., aFlags=<optimized out>)
    at ../../../gecko/layout/base/nsPresShell.cpp:5932
#31 0xb5e07214 in nsViewManager::ProcessPendingUpdatesPaint (this=0xb38e0730, aWidget=aWidget@entry=0xb4154110)
    at ../../../gecko/view/src/nsViewManager.cpp:456
#32 0xb5e07354 in nsViewManager::ProcessPendingUpdatesForView (this=this@entry=0xb3f02e60, aView=<optimized out>, 
    aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at ../../../gecko/view/src/nsViewManager.cpp:397
#33 0xb5e073d6 in nsViewManager::ProcessPendingUpdates (this=this@entry=0xb38e0730)
    at ../../../gecko/view/src/nsViewManager.cpp:1088
#34 0xb601b892 in nsRefreshDriver::Tick (this=0xb3f02e60, aNowEpoch=<optimized out>, aNowTime=...)
    at ../../../gecko/layout/base/nsRefreshDriver.cpp:1207
#35 0xb601bc24 in TickDriver (now=..., jsnow=1411520224345858, driver=<optimized out>)
    at ../../../gecko/layout/base/nsRefreshDriver.cpp:168
#36 mozilla::RefreshDriverTimer::Tick (this=<optimized out>) at ../../../gecko/layout/base/nsRefreshDriver.cpp:160
#37 0xb56e2ed6 in nsTimerImpl::Fire (this=0xb3874940) at ../../../gecko/xpcom/threads/nsTimerImpl.cpp:562
#38 0xb56e2f92 in nsTimerEvent::Run (this=0xb38b4150) at ../../../gecko/xpcom/threads/nsTimerImpl.cpp:646
#39 0xb56e127e in ProcessNextEvent (result=0xbebaed97, mayWait=<optimized out>, this=0xb48025c0)
    at ../../../gecko/xpcom/threads/nsThread.cpp:694
#40 nsThread::ProcessNextEvent (this=0xb48025c0, mayWait=<optimized out>, result=0xbebaed97)
    at ../../../gecko/xpcom/threads/nsThread.cpp:618
#41 0xb56b4c2a in NS_ProcessNextEvent (thread=<optimized out>, mayWait=mayWait@entry=false)
    at ../../../gecko/xpcom/glue/nsThreadUtils.cpp:263
#42 0xb58175ec in mozilla::ipc::MessagePump::Run (this=0xb4801af0, aDelegate=0xbebaee98)
    at ../../../gecko/ipc/glue/MessagePump.cpp:95
#43 0xb580bfa6 in MessageLoop::RunInternal (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#44 0xb580c058 in RunHandler (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#45 MessageLoop::Run (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#46 0xb5c6749a in nsBaseAppShell::Run (this=0xb40d1ac0) at ../../../gecko/widget/xpwidgets/nsBaseAppShell.cpp:164
#47 0xb623a336 in XRE_RunAppShell () at ../../../gecko/toolkit/xre/nsEmbedFunctions.cpp:679
#48 0xb580bfa6 in MessageLoop::RunInternal (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#49 0xb580c058 in RunHandler (this=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#50 MessageLoop::Run (this=this@entry=0xbebaee98) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#51 0xb623a6be in XRE_InitChildProcess (aArgc=6, aArgv=<optimized out>, aProcess=<optimized out>)
    at ../../../gecko/toolkit/xre/nsEmbedFunctions.cpp:516
#52 0x000086ee in main (argc=8, argv=0xbebaf824) at ../../../gecko/ipc/app/MozillaRuntimeMain.cpp:149
(gdb) frame 14
#14 0xb5a39bc8 in mozilla::layers::GrallocTextureClientOGL::AllocateForSurface (this=<optimized out>, aSize=...)
    at ../../../gecko/gfx/layers/opengl/GrallocTextureClient.cpp:325
325	  return AllocateGralloc(aSize, format, usage);
(gdb) p aSize
$1 = {<mozilla::gfx::BaseSize<int, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> >> = {width = 2916, 
    height = 3888}, <mozilla::gfx::UnknownUnits> = {<No data fields>}, <No data fields>}
(Reporter)

Comment 14

3 years ago
Base on the call stack we get this piece of memory allcating when gfx began to paint the preview of pictures.
(In reply to ben.song from comment #11)
> Dear Danny,
> 
> Base on my analysis,I find adbd has no problem and I don't know why no log
> from 08-18 11:09:02 to 08-20 12:00:56.But I find allcation of a piece memory
> of 2916*3888 could bring big pressure to kernel.
> About this piece memory,we find the route to reproduce it:
> 1.Open gallery app or camera app.(must have many picture in it)
> 2.Open the preview of first picture.
> 3.Slide picture to the preview of next picture quickly and constantly. 
> 
> About above reproduce i have several question:
> 1.We don't know whether the piece memory be fine.
> 2.if it is fine,can we avoid allcating the piece memory like that ?Because
> at the moment of low memory,this piece memory would bring crash of some app
> or system probably.

Hi Vincent,
Could you help to check if the memory allocation is reasonable?

Breakpoint 1, alloc_device_alloc (dev=0xb6a02550, w=2916, h=3888, format=1, usage=307, pHandle=0xb1726f44, pStride=0xb1726f30)
    at vendor/sprd/open-source/libs/gralloc/alloc_device.cpp:494

Hi Ben,
According comment 8 and my previous analysis, suggest to have available sysdump or jtag environment to analyze this hang issue.
Gary has restricted the camera picture size in Bug 1041853, but the issue still happened.
Big size memory allocation should not cause system hang, we suspected there is deadlock when doing memory allocation. If reducing the size of memory allocation cannot reproduce the issue, it just avoid the problem rather than fix it. So please understand my concern and try to get available sysdump or jtag environment to analyze this hang issue.
Flags: needinfo?(vliu)
Flags: needinfo?(dliang)
Flags: needinfo?(ben.song)

Comment 16

3 years ago
Hi Ben,

I cann't reproduce it by your way. Some questions are as follow 

> 1.Open gallery app or camera app.(must have many picture in it)
> 2.Open the preview of first picture.
> 3.Slide picture to the preview of next picture quickly and constantly. 

Q1: Do I need specific pictures to reproduce it?
Q2. How about the fail rate?
Flags: needinfo?(vliu)
(Reporter)

Comment 17

3 years ago
(In reply to Vincent Liu[:vliu] from comment #16)
> Hi Ben,
> 
> I cann't reproduce it by your way. Some questions are as follow 
> 
> > 1.Open gallery app or camera app.(must have many picture in it)
> > 2.Open the preview of first picture.
> > 3.Slide picture to the preview of next picture quickly and constantly. 
> 
> Q1: Do I need specific pictures to reproduce it?
> Q2. How about the fail rate?

Hi Vincent,

  I reprodce it sometimes.I think it has high reproduce rate after several hours monkey test.
  The rate of this problem happens in monkey test is high,but reproduce by myself is low,I think we could place many pictures and videos in gallery.
Flags: needinfo?(ben.song)

Comment 18

3 years ago
What size of pictures you used?

Comment 19

3 years ago
Would you please attach the pictures you used? It can sync the environment in both side.
(Reporter)

Comment 20

3 years ago
(In reply to Vincent Liu[:vliu] from comment #19)
> Would you please attach the pictures you used? It can sync the environment
> in both side.

Hi Vincent,

   My pictures is attached by monkey test and has been cleaned,you can first do monkey test,it would add some pictures and videos in the mobile.The size of pictures and videos,is quite normal,has not big pictures.
   You can see gecko/gfx/layers/opengl/GrallocTextureClient.cpp,In function GrallocTextureClientOGL::AllocateForSurface,there is RGBA 8888,I think the piece of memory is allcated in here.
Flags: needinfo?(yanbin.fang)
(Reporter)

Comment 21

3 years ago
It alway happens at the moment of memory pressure.The rate is high when monkey test and memory pressure.
Flags: needinfo?(vliu)
Hi Ben,
This issue is reported on 7/21, we have setup monkey test several times but we can not reproduce it.
I think it will be better if you can provide the STR with higher reproduce rate, and then our RD can address the problem effectively.
After sync with Vincent, we cannot reproduce it by both manual and monkey test. Could you please provide the STR and contents? We suspected it might be related to contents.
Moreover, do you apply any patch regarding camera and graphic?
Flags: needinfo?(ben.song)

Comment 23

3 years ago
Hi Ben,
Based on Danny' comment, could you please offer give me enough information so I can look into the problem? Thanks
Flags: needinfo?(vliu)
(Reporter)

Comment 24

3 years ago
(In reply to Danny Liang [:dliang] from comment #22)
> Hi Ben,
> This issue is reported on 7/21, we have setup monkey test several times but
> we can not reproduce it.
> I think it will be better if you can provide the STR with higher reproduce
> rate, and then our RD can address the problem effectively.
> After sync with Vincent, we cannot reproduce it by both manual and monkey
> test. Could you please provide the STR and contents? We suspected it might
> be related to contents.
> Moreover, do you apply any patch regarding camera and graphic?

Dear Danny,

1.I would find a way of reproduce this problem manually and help you to analysis it.
2.We have reproduced it several times in monkey test,but I don't know whether have any patch regarding camera effected it and we have not made patch regarding graphic without mozilla patch.

Thanks for your help.

Dear Vincent,

Our QA could reproduce this problem through monkey test,and we can see the big memory through main log.But I have low reproduce rate manually,we don't know how can it reproduce but we would try to get a better reproduce way.
Flags: needinfo?(ben.song) → needinfo?(vliu)

Comment 25

3 years ago
(In reply to ben.song from comment #24)

> Dear Vincent,
> 
> Our QA could reproduce this problem through monkey test,and we can see the
> big memory through main log.But I have low reproduce rate manually,we don't
> know how can it reproduce but we would try to get a better reproduce way.

Clear the ni? and wait for more detailed info to analysis.
Flags: needinfo?(vliu)

Updated

2 years ago
tracking-b2g: --- → -
You need to log in before you can comment on or make changes to this bug.