1995443 - Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | mozilla::Vector<T>::operator[] | ProfileBuffer::MaybeStreamExecutionTraceToJSON<T>]

Status: ASSIGNED

(Core :: Gecko Profiler, defect, P2)

Description

[BugBot [:suhaib / :marco/ :calixte]]

Crash report: https://crash-stats.mozilla.org/report/index/e3a49185-6f7f-406b-b53d-0a0560251016

MOZ_CRASH Reason: ElementAt(aIndex = 10116, aLength = 10116)

Top 10 frames of crashing thread:

0  libmozglue.dylib  MOZ_CrashSequence  mfbt/Assertions.h:242
0  libmozglue.dylib  MOZ_Crash  mfbt/Assertions.h:375
0  libmozglue.dylib  mozilla::detail::InvalidArrayIndex_CRASH  mfbt/Assertions.cpp:77
1  XUL  mozilla::Vector<char,   mfbt/Vector.h:587
1  XUL  ProfileBuffer::MaybeStreamExecutionTraceToJSON<ProfileBuffer::StreamSamplesAndMarkersToJSON const  tools/profiler/core/ProfileBufferEntry.cpp
1  XUL  ProfileBuffer::StreamSamplesAndMarkersToJSON const  tools/profiler/core/ProfileBufferEntry.cpp:1708
2  XUL  locked_profiler_stream_json_for_this_process  tools/profiler/core/platform.cpp:3863
3  XUL  do_profiler_stream_json_for_this_process  tools/profiler/core/platform.cpp:4003
4  XUL  profiler_stream_json_for_this_process  tools/profiler/core/platform.cpp:4027
5  XUL  WriteProfileToJSONWriter  tools/profiler/core/platform.cpp:6251

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2025-10-16
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - all crashes happened on null or near null memory address

By analyzing the backtrace, the regression may have been introduced by a patch [1] to fix Bug 1769188.

[1] https://hg.mozilla.org/mozilla-central/rev?node=685fcd2b7261

:sergesanspaille, since you are the author of the potential regressor, could you please take a look?

Comment 1

[Andrew McCreight [:mccr8]]

The immediate regressor here is clearly bug 1445260, but I'm pretty sure this is just finding some pre-existing issue with the profiler. I looked at it a bit but I couldn't figure out what might be going wrong. These are all large-ish arrays where the index is equal to the length, so there's some kind of off by one error, maybe, but I couldn't tell where the access was.

Comment 2

[Andrew McCreight [:mccr8]]

Canova, any idea what might be going on here? Also, am I right in thinking that the profiler is only enabled on Nightly? I'd like to backport bug 1445260 to older branches but not if it is going to cause problems. Thanks.

Comment 3

[[:sergesanspaille]]

I fail to understand how the move from MOZ_TRY_VAR to MOZ_TRY is causing an issue there? Andrew, that's what you're hinting at, right?

Comment 4

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

The profiler is normally enabled pretty much everywhere (minus some tier 3 platforms). BUT this method belongs to a feature called "execution tracing" and that is nightly only currently. So it should be safe to uplift, if it only affect the execution tracking part (seems like it from the crash report as long as we don't have another report somewhere else). And in the meantime we can take a look to fix that part.

:sergesanspaille, I think that MOZ_TRY bug was marked as a mistake, and it looks like it's removed. The correct one seems to be bug 1445260.

Comment 5

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

@Alex, do you know why this might be happening in the execution tracing code?

Comment 6

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Hmm, looking at the string buffer, this is the location where we set this stringBufferOffset:
https://searchfox.org/firefox-main/rev/8e5d58cfed616cb90586c614e53d8ab1ffc8af27/js/src/debugger/ExecutionTracer.cpp#433
Then we call outOfLineData_.readString in the line below to append that to the string buffer. But this method might fail and return false.

What happens in that case, do we discard the whole thing, or do we still keep it and then eventually try to serialize it?

I think instead of passing a dummyIndex here, we should use that value and assign that one to stringBufferOffset after the if check:
https://searchfox.org/firefox-main/rev/8e5d58cfed616cb90586c614e53d8ab1ffc8af27/js/src/debugger/ExecutionTracer.cpp#435-439

But then we might need to have way to make stringBufferOffset optional?

Comment 7

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Hmm, wait, shapes.append(shape) happens after that if check. So otherwise we don't append it. So this should be safe...
https://searchfox.org/firefox-main/rev/8e5d58cfed616cb90586c614e53d8ab1ffc8af27/js/src/debugger/ExecutionTracer.cpp#506-508

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 9

[Andrew McCreight [:mccr8]]

IIUC this is Nightly-only.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1445260