1998263 - Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | nsTArray_Impl<T>::ElementAt | nsTArray_Impl<T>::operator[] | mozilla::dom::Geolocation::NotifyError]

Status: NEW

(Core :: DOM: Geolocation, defect, P2)

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/ca4a3791-ed07-4e6f-b92e-8037f0251104

MOZ_CRASH Reason:

ElementAt(aIndex = 0, aLength = 0)

Top 10 frames:

0  libmozglue.so  MOZ_CrashSequence(void*, long)  mfbt/Assertions.h:253
0  libmozglue.so  MOZ_Crash(char const*, int, char const*)  mfbt/Assertions.h:381
0  libmozglue.so  mozilla::detail::InvalidArrayIndex_CRASH(unsigned long, unsigned long)  mfbt/Assertions.cpp:77
1  libxul.so  nsTArray_Impl<RefPtr<nsGeolocationRequest>, nsTArrayInfallibleAllocator>::Ele...  xpcom/ds/nsTArray.h:1069
1  libxul.so  nsTArray_Impl<RefPtr<nsGeolocationRequest>, nsTArrayInfallibleAllocator>::ope...  xpcom/ds/nsTArray.h:1116
1  libxul.so  mozilla::dom::Geolocation::NotifyError(unsigned short)  dom/geolocation/Geolocation.cpp:1205
2  libxul.so  nsGeolocationService::NotifyError(unsigned short)  dom/geolocation/Geolocation.cpp:856
3  libxul.so  mozilla::dom::ContentChild::RecvGeolocationError(unsigned short const&)  dom/ipc/ContentChild.cpp:2383
4  libxul.so  mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&)  ipc/ipdl/PContentChild.cpp:10363
5  libxul.so  mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecyc...  ipc/glue/MessageChannel.cpp:1797

In bug 1996652, I split up these invalid array access signatures a bit. This one popped out as the third most common crash.

Maybe a call to NotifyErrorAndShutdown from a prior iteration of the loop modified mPendingCallbacks? This looks dodgy.

Funnily enough, we had bug 1517250 on file for this many years ago.

Almost all of these have index 0 and length 0, but 4 of them have non-zero indices (1, 2, 3 and 7).

Comment 1

[Eden Chuang[:edenchuang]]

NotifyErrorAndShutdown() removes one element at a time, and it is supposed to be okay for the outer for loop, which decreases the index by 1.

Regarding Andrew's analysis about index 0 and lengh 0, it must be something wrong with index management. Perhaps it would be better to use iterators for the for loop instead of using the index.