1643517 - Crash in [@ InvalidArrayIndex_CRASH | mozilla::layers::InputQueue::ProcessQueue]

Status: RESOLVED DUPLICATE of bug 1643884

(Core :: Panning and Zooming, defect)

Description

[Andrew McCreight [:mccr8]]

This bug is for crash report bp-b61945a3-1d11-461a-9562-dceb50200603.

Top 10 frames of crashing thread:

0 XUL InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:27
1 XUL mozilla::layers::InputQueue::ProcessQueue gfx/layers/apz/src/InputQueue.cpp
2 XUL mozilla::layers::InputQueue::ReceiveInputEvent gfx/layers/apz/src/InputQueue.cpp:57
3 XUL mozilla::layers::APZCTreeManager::ReceiveInputEvent gfx/layers/apz/src/APZCTreeManager.cpp:1727
4 XUL non-virtual thunk to mozilla::layers::APZCTreeManager::ReceiveInputEvent gfx/layers/apz/src/APZCTreeManager.cpp
5 XUL nsChildView::DispatchAPZInputEvent widget/cocoa/nsChildView.mm:2063
6 XUL -[ChildView magnifyWithEvent:] widget/cocoa/nsChildView.mm:2848
7 AppKit -[NSWindow _reallySendEvent:isDelayedEvent:] 
8 AppKit -[NSWindow sendEvent:] 
9 XUL -[ToolbarWindow sendEvent:] widget/cocoa/nsCocoaWindow.mm:3732

4 crashes with this signature, starting with the 20200601093812 build. The crash reason for them all is ElementAt(aIndex = 0, aLength = 0), so something is trying to do something with an empty queue it looks like. It looks like the crashes are all happening in InputQueue::ReceivePinchGestureInput, but there's no line number for the actual crash.

Comment 1

[Andrew McCreight [:mccr8]]

Maybe this is related to "desktop zooming"? The first crash was a few days after the email about it.

Comment 2

[Botond Ballo [:botond]]

Definitely related to desktop zooming, though the reason for the crash is not immediately clear. The array accesses that occur directly in ProcessQueue() are guarded against the queue being empty, and the function should only be called on one thread.

Comment 3

[Timothy Nikkel (:tnikkel)]

Looks like it started in the build 20200601093812. Combining the cpu info and the adaptor id (gpu) it looks like 3 systems are responsible for the 16 crashes. There is at least one crash for a buildid for every date in June except June 7, so something that landed in the range of 1-2 days before the June 1 build could be looked at for potential regressors.

Comment 4

[Botond Ballo [:botond]]

Here's a 2-day window before the June 1 build:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=548ffce7ad571850fdcb024ae3459855230ebd35&tochange=bc973d369db58faf254ddcef201089dc28e6d3be

Nothing particularly jumps out. Widening to 3 days:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a58cc68b0c51645d34cbc7f8f8a30edae77ab396&tochange=bc973d369db58faf254ddcef201089dc28e6d3be

the range now contains bug 1641996, but that's a Windows-only change and this is a Mac crash, so not it.

Comment 5

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

I think the most likely explanation is that this was introduced by the pinch handling code, but the codepath only got activated when people flipped the apz.allow_zooming pref manually, and for some users that seems to be causing this crash.

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Hi Botond, can you set a severity? If this is caused by a user pref flip, it doesn't sound too severe.

Comment 7

[Botond Ballo [:botond]]

S3 for a crash that only occurs with a modified pref. This bug does block bug 1620055, so should be fixed before the pref is enabled by default.

Comment 8

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

Some STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1643884

Comment 9

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

I have a patch in bug 1643884