1869203 - Crash in [@ mozilla::detail::nsTStringLengthStorage<T>::nsTStringLengthStorage]

Status: NEW

(Core :: XPCOM, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/b543e3bc-9de7-44aa-8e82-97dff0231206

Reason: EXCEPTION_ILLEGAL_INSTRUCTION

Top 10 frames of crashing thread:

0  xul.dll  mozilla::detail::nsTStringLengthStorage<char>::nsTStringLengthStorage  xpcom/string/nsTStringRepr.h:85
0  xul.dll  nsTAutoStringN<char, 64>::nsTAutoStringN  xpcom/string/nsTString.h:267
0  xul.dll  nsTAutoStringN<char, 64>::nsTAutoStringN  xpcom/string/nsTString.h:290
0  xul.dll  StringJoin  xpcom/string/nsReadableUtils.h:485
0  xul.dll  mozilla::dom::CopyHandlerInfoTonsIHandlerInfo  uriloader/exthandler/ContentHandlerService.cpp:163
1  xul.dll  mozilla::dom::ContentHandlerService::GetMIMEInfoFromOS  uriloader/exthandler/ContentHandlerService.cpp:202
2  xul.dll  nsOSHelperAppServiceChild::GetMIMEInfoFromOS  uriloader/exthandler/nsOSHelperAppServiceChild.cpp:95
3  xul.dll  nsExternalHelperAppService::GetMIMETypeFromOSForExtension  uriloader/exthandler/nsExternalHelperAppService.cpp:3181
4  xul.dll  nsExternalHelperAppService::GetTypeFromExtension  uriloader/exthandler/nsExternalHelperAppService.cpp:2932
5  xul.dll  nsJARChannel::GetContentTypeGuess const  modules/libjar/nsJARChannel.cpp:772

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

• First crash report: 2023-11-17
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 15 crashes happened on null or near null memory address

Comment 1

[Gabriele Svelto [:gsvelto]]

The crash in comment 0 is not really representative of this signature. It's probably caused by bad hardware. On the other hand we have a fair amount of Android-specific crashes like this one: https://crash-stats.mozilla.org/report/index/d7393627-8129-4177-a80e-894230231209

These all come from devices based on the Exynos 7870 SoC, which makes me suspect this could be a hardware bug.

Comment 2

[Jens Stutte [:jstutte]]

Yeah, it seems there are different flavors of this crash coming from different call paths.
All Android and Linux and some Windows crashes all have this release assertion which might also indicate a real problem (like very long strings) ?

Moving this to XPCOM for further triage, FWIW.

Comment 3

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

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

For more information, please visit BugBot documentation.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

This release assertion is fired if we try to create a nsTString which would be more than INT32_MAX bytes long (~2GB), as we have a ton of legacy code which uses types like int, int32_t, or uint32_t and assumes string lengths can fit within them. This acts as a defensive measure to ensure that that code continues working. The assertion was added in bug 1741665.

Usually in most places we'd encounter an OOM error rather than hitting this crash (though that could lead to an OOM crash) because we're trying to allocate a gigantic string buffer and we fail to allocate any string buffers that large. In the case in comment 1, however, we are able to hit the assertion because we're constructing a nsDependentString for an already-allocated string buffer, which is generally infallible (https://hg.mozilla.org/releases/mozilla-release/file/d80eefe94738ab6bd35cca64747d877c49337318/js/xpconnect/src/XPCComponents.cpp#l1425).

It might be worthwhile to add some form of string truncation or other handling in that specific call-site for extremely long source lines, both because it's causing a problem here, and to avoid doing unnecessary string manipulation, as we probably don't want to be sending a 2gig string literal over IPC to report it to the console anyway. If there are other locations like this which are running into the crash, we could also look into adding checks for those. I don't think there's anything productive we can do in the xpcom string code.