1134917 - B2G: MOZ_ASSERT(aGuid == mPendingTouchPreventedGuid); gfx/layers/apz/util/APZEventState.cpp:310

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Gregor Wagner [:gwagner]]

On current trunk on flame with debug gecko during zooming on cnn.com

Program received signal SIGSEGV, Segmentation fault.
0xb46e3374 in SendPendingTouchPreventedResponse (this=<optimized out>, aPreventDefault=<optimized out>, aGuid=...) at ../../../gfx/layers/apz/util/APZEventState.cpp:310
310	    MOZ_ASSERT(aGuid == mPendingTouchPreventedGuid);
(gdb) MOZ_
Undefined command: "MOZ_".  Try "help".
(gdb) bt
#0  0xb46e3374 in SendPendingTouchPreventedResponse (this=<optimized out>, aPreventDefault=<optimized out>, aGuid=...) at ../../../gfx/layers/apz/util/APZEventState.cpp:310
#1  mozilla::layers::APZEventState::SendPendingTouchPreventedResponse (this=0xad569ec0, aPreventDefault=<optimized out>, aGuid=...) at ../../../gfx/layers/apz/util/APZEventState.cpp:306
#2  0xb505f898 in nsBaseWidget::DispatchEventForAPZ (this=this@entry=0xb07cb030, aEvent=aEvent@entry=0xbec71748, aGuid=..., aInputBlockId=aInputBlockId@entry=484) at ../../widget/nsBaseWidget.cpp:1005
#3  0xb5086e74 in nsWindow::DispatchTouchEventForAPZ (this=0xb07cb030, aInput=..., aGuid=..., aInputBlockId=aInputBlockId@entry=484) at ../../../widget/gonk/nsWindow.cpp:329
#4  0xb5086ea6 in DispatchTouchInputOnMainThread::Run (this=<optimized out>) at ../../../widget/gonk/nsWindow.cpp:261
#5  0xb4215e24 in nsThread::ProcessNextEvent (this=0xb249d320, aMayWait=<optimized out>, aResult=0xbec71837) at ../../../xpcom/threads/nsThread.cpp:855
#6  0xb422b04c in NS_ProcessNextEvent (aThread=0xb249d320, aMayWait=aMayWait@entry=false) at /Volumes/2mac/moz/ib2g/xpcom/glue/nsThreadUtils.cpp:265
#7  0xb43e1f48 in mozilla::ipc::MessagePump::Run (this=0xb6aff1c0, aDelegate=0xb24bd1a0) at ../../../ipc/glue/MessagePump.cpp:99
#8  0xb43cdcf0 in MessageLoop::RunInternal (this=this@entry=0xb24bd1a0) at ../../../ipc/chromium/src/base/message_loop.cc:233
#9  0xb43cdd0a in RunHandler (this=0xb24bd1a0) at ../../../ipc/chromium/src/base/message_loop.cc:226
#10 MessageLoop::Run (this=0xb24bd1a0) at ../../../ipc/chromium/src/base/message_loop.cc:200
#11 0xb5061bee in nsBaseAppShell::Run (this=0xb276a4c0) at ../../widget/nsBaseAppShell.cpp:164
#12 0xb54a0e8a in nsAppStartup::Run (this=0xb6a92a00) at ../../../../toolkit/components/startup/nsAppStartup.cpp:281
#13 0xb54d0c28 in XREMain::XRE_mainRun (this=this@entry=0xbec719c0) at ../../../toolkit/xre/nsAppRunner.cpp:4160
#14 0xb54d0dfc in XREMain::XRE_main (this=this@entry=0xbec719c0, argc=argc@entry=1, argv=argv@entry=0xb6a2b198, aAppData=aAppData@entry=0xb6f3d858 <_ZL8sAppData>) at ../../../toolkit/xre/nsAppRunner.cpp:4236
#15 0xb54d0f76 in XRE_main (argc=1, argv=0xb6a2b198, aAppData=0xb6f3d858 <_ZL8sAppData>, aFlags=<optimized out>) at ../../../toolkit/xre/nsAppRunner.cpp:4456
#16 0xb6f2213a in do_main (argc=argc@entry=1, argv=argv@entry=0xb6a2b198) at ../../../b2g/app/nsBrowserApp.cpp:167
#17 0xb6f22276 in b2g_main (argc=argc@entry=1, argv=argv@entry=0xbec72c94) at ../../../b2g/app/nsBrowserApp.cpp:299
#18 0xb6f21fa4 in RunProcesses (aReservedFds=..., argv=0xbec72c94, argc=1) at ../../../b2g/app/B2GLoader.cpp:225
#19 main (argc=1, argv=0xbec72c94) at ../../../b2g/app/B2GLoader.cpp:290

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Did it happen right when you started zooming? Or partway through the zoom?

Comment 2

[Gregor Wagner [:gwagner]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #1)
> Did it happen right when you started zooming? Or partway through the zoom?

Always hard to remember what I did during exploratory testing. I remember that I did some crazy zooming. It wasn't the first zooming but I can't say if it was at the beginning or during this single zoom event.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I tried reproducing for a while doing different zooming actions on cnn.com but was unable to. If you can repro again please try to find STR. It's not obvious to me from a code inspection why this might happen, and probably indicates a real bug somewhere.

Comment 4

[Botond Ballo [:botond]]

I ran into this while running monkey tests locally.

Comment 5

[No-Jun Park [:njpark]]

I also ran into this today, with following assert:

F/MOZ_Assert( 3178): Assertion failure: aGuid == mPendingTouchPreventedGuid, at /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/gfx/layers/apz/util/APZEventState.cpp:391 

I was on email app when it froze, and i tried to tap the options button on the top left corner.  Then it crashed shortly after giving the assert failure.

Comment 6

[Gregor Wagner [:gwagner]]

This happened also in the Settings APP when displaying a simple Select overlay for SIM card usage.

Comment 7

[Gregor Wagner [:gwagner]]

What are the next steps here? I usually run into this within 20 min of monkey testing. I am happy to add a logging patch.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Logging patch

Thanks. Here's a logging patch that should provide some more info.

Comment 9

[Gregor Wagner [:gwagner]]

Attachment: logcat

Comment 10

[Gregor Wagner [:gwagner]]

0xb4400f16 in SendPendingTouchPreventedResponse (aGuid=..., aPreventDefault=false, this=0xaae40080) at /Volumes/2mac/moz/ib2g/gfx/layers/apz/util/APZEventState.cpp:408
408	    MOZ_ASSERT(aGuid == mPendingTouchPreventedGuid);
(gdb) p this
$1 = (mozilla::layers::APZEventState * const) 0xaae40080
(gdb) p *this
$2 = {mRefCnt = {static isThreadSafe = false, mValue = 2}, _mOwningThread = {mThread = 0xb6a4a080}, mWidget = {mRawPtr = 0xae8561d0}, mActiveElementManager = {mRawPtr = 0xac57c6e0}, 
  mContentReceivedInputBlockCallback = {mRawPtr = 0xae8561a0}, mPendingTouchPreventedResponse = true, mPendingTouchPreventedGuid = {mLayersId = 1, mPresShellId = 3, mScrollId = 2}, 
  mPendingTouchPreventedBlockId = 304, mEndTouchIsClick = true, mTouchEndCancelled = false, mActiveAPZTransforms = 0}
(gdb)

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Thanks! The last few lines of the log explain what's going on:
- APZ gets a touchstart, it has a tentative target guid=(1,3,2)
- The main-thread processing of the touchstart goes to the child process with this tentative guid
- The child process finds a target guid=(1,1,3) and sends the confirmed target notification to the APZ.
- The APZ updates its tentative target to the new confirmed target
- The child process stashes the tentative guid into mPendingTouchPreventedGuid
- A longpress is detected, so the APZ starts a new input block using the confirmed target from the previous block
- The ProcessLongTap function is called with the confirmed guid, but the mPendingTouchPreventedGuid is the tentative guid

Conceptually it doesn't make sense to pass in aGuid from ProcessLongTap to SendPendingTouchPreventedResponse because the long-tap guid is from a new event block and there's no real reason to expect it will be the same as mPendingTouchPreventedGuid. I'll write up a patch for this.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

Comment 13

[Botond Ballo [:botond]]

Comment on attachment 8638129 [details] [diff] [review]
Patch

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

Note that, as discussed on IRC, the reason this problem doesn't affect the call to SendPendingTouchPreventedResponse() that happens for a touch-move is that APZ caches the original (tentative) target APZC for an input block (in APZCTreeManager::mApzcForInputBlock), and sends the guid of that, rather than the guid of the confirmed target APZC. Since a touch-move doesn't start a new input block, the tentative guid is sent.

Comment 14

[Pulsebot]

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

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a157bac2cdae