Open Bug 1870379 Opened 5 months ago Updated 4 months ago

Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsTArray_Impl<T>::operator[] | mozilla::dom::Gamepad::SetButton]

Categories

(Core :: DOM: Device Interfaces, defect, P3)

Unspecified
Windows 11
defect

Tracking

()

People

(Reporter: mccr8, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/a03ec71f-d449-43d3-81a1-e79ac0231215

Reason: EXCEPTION_BREAKPOINT

Top 10 frames of crashing thread:

0  mozglue.dll  MOZ_Crash  mfbt/Assertions.h:281
0  mozglue.dll  mozilla::detail::InvalidArrayIndex_CRASH  mfbt/Assertions.cpp:50
1  xul.dll  nsTArray_Impl<RefPtr<mozilla::dom::GamepadButton>, nsTArrayInfallibleAllocator>::ElementAt  xpcom/ds/nsTArray.h:1208
1  xul.dll  nsTArray_Impl<RefPtr<mozilla::dom::GamepadButton>, nsTArrayInfallibleAllocator>::operator[]  xpcom/ds/nsTArray.h:1245
1  xul.dll  mozilla::dom::Gamepad::SetButton  dom/gamepad/Gamepad.cpp:88
2  xul.dll  mozilla::dom::GamepadManager::SetGamepadByEvent  dom/gamepad/GamepadManager.cpp:540
3  xul.dll  mozilla::dom::GamepadManager::Update  dom/gamepad/GamepadManager.cpp:466
4  xul.dll  mozilla::dom::  dom/gamepad/ipc/GamepadEventChannelChild.cpp:21
5  xul.dll  mozilla::RunnableTask::Run  xpcom/threads/TaskController.cpp:549
5  xul.dll  mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal  xpcom/threads/TaskController.cpp:876

The volume isn't super high here but I figured I'd file it in case there was something useful to be done. It looks like the button value passed in to SetButton does not fall within the mButtons array. I don't see the array bounds crash annotation which is odd.

The severity field is not set for this bug.
:cmartin, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(cmartin)

Might be worth investigating. There is a known synchronization issue on Mac OS X where the gamepad monitor thread will continue to deliver events after shutdown was requested because the requesting thread doesn't actually wait() on the shutdown to complete before it deletes all its state objects. Normally, this is not a huge problem since the GamepadManager will just silently ignore events if it's already deleted everything; however, in some cases it can do weird things... This may be one of them.

It has been on my todo list forever to fix this, but there's just never any time to work on gamepad stuff these days.

Severity: -- → S3
Flags: needinfo?(cmartin)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.