1550951 - startup Crash in [@ mozilla::dom::DocumentL10n::Init] related to omni.ja corruption

Status: RESOLVED FIXED

(Core :: Internationalization, defect, P2)

Description

[[:philipp]]

This bug is for crash report bp-c462e041-f4fb-49b0-b1c9-5c3c10190510.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::DocumentL10n::Init intl/l10n/DocumentL10n.cpp:98
1 xul.dll mozilla::dom::Document::InitializeLocalization dom/base/Document.cpp:3126
2 xul.dll mozilla::dom::Document::OnL10nResourceContainerParsed dom/base/Document.cpp:3202
3 xul.dll nsresult mozilla::dom::PrototypeDocumentContentSink::ResumeWalk dom/prototype/PrototypeDocumentContentSink.cpp:449
4 xul.dll nsXULPrototypeDocument::NotifyLoadDone dom/xul/nsXULPrototypeDocument.cpp:403
5 xul.dll nsresult XULContentSinkImpl::DidBuildModel dom/xul/nsXULContentSink.cpp:197
6 xul.dll nsresult nsParser::ResumeParse parser/htmlparser/nsParser.cpp:1008
7 xul.dll nsresult nsParser::OnStopRequest parser/htmlparser/nsParser.cpp:1354
8 xul.dll nsresult nsDocumentOpenInfo::OnStopRequest uriloader/base/nsURILoader.cpp:360
9 xul.dll nsresult nsJARChannel::OnStopRequest modules/libjar/nsJARChannel.cpp:1026

this is a low volume crash signature starting to show up in firefox 67 with
MOZ_RELEASE_ASSERT(jsm) or MOZ_RELEASE_ASSERT(mDOMLocalization) added in bug 1523194.

Comment 1

[Pascal Chevrel:pascalc]

low volume, wontfix 67

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Still quite low volume. Marking fix-optional for 69 as well to get this out of regression triage.

Comment 3

[Marcia Knous [:marcia]]

Adding another signature seen during triage. These either have moz crash reason MOZ_RELEASE_ASSERT(jsm) or MOZ_RELEASE_ASSERT(mLocalization).

Comment 4

[Marcia Knous [:marcia]]

Marking fix optional per triage team.

Comment 5

[Marcia Knous [:marcia]]

Adding 71 as affected, although crashes there are fairly sparse. This is the #12 top content crash in 70.0rc2.

Comment 6

[Pascal Chevrel:pascalc]

Makoto, could you help us find an owner for this bug please? Thanks

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

Kris, can you advice me here?

The crash is coming from:

nsCOMPtr<mozILocalizationJSM> jsm =
    do_ImportModule("resource://gre/modules/Localization.jsm  ");
MOZ_RELEASE_ASSERT(jsm);

and I don't know how to reproduce it or investigate it, or even how to handle it.
The Localization.jsm has no "runtime" code, and only register its functions so I doubt that it throws any exception intermittently just on loading.

I have a couple hypothesis:

1. We've observed cases where JS code on user machine is contaiminated with a random character breaking JS (see 1594453 comment 17)
2. Something happens that makes the loading of the module impossible (OOM?)

In both cases, we are out of luck and need to abort, but I don't know how we should do it to avoid crashing?
Is there a way to gather more information why do_ImportModule didn't succeed?

Comment 8

[Kris Maglione [:kmag]]

This is probably the same issue as bug 1403348, which we're pretty sure at this point is either omnijar or memory corruption. There really isn't any better option than to crash in that case. If omnijar is corrupt, we can't trust anything, and we're better off not running at all.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Is the volume acceptable for marking this as WONTFIX then? I'm concerned about high volume of omnijar or memory corruption that somehow particularly addresses Localization.jsm, so I'm wondering if other do_importModule cases register comparable volume.

Comment 10

[Kris Maglione [:kmag]]

I'd be inclined to just mark it as a dupe of bug 1403348. What we really need for both issues is a way to detect and report (to the user) or recover from (by reinstalling) omni jar corruption at runtime. Other than that, there really isn't anything we can do.

Or, well, I suppose we could special case the specific cases where we crash if we fail to load a module to also tell users their Firefox installation is probably corrupt... That might not be so bad as a short term solution, but omni jar corruption manifests in so many other ways that I'm not sure there's a point in playing whack-a-mole that way.

Comment 11

[Pascal Chevrel:pascalc]

We have shipped our last beta for 71 and the bug is unassigned, so this is wontfix for 71.

Comment 12

[Jim Mathies [:jimm]]

Hey, this seems to be getting worse, and may have regressed in september. Should we re-prioritize this?

Comment 13

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm not the right person to triage it.

The crash is not really related to Intl logic, but to the do_ImportModule logic. As Kris stated in comment 10, there's likely not much we can salvage if that happens, so I don't know how to improve the situation.

In the long run we'll migrate Localization to Rust, but that will likely just push the crash to the next do_ImportModule use case which will crash.

I'll redirect the NI to Kris in case he sees anything actionable here.

Comment 14

[Kris Maglione [:kmag]]

It has nothing to do with do_ImportModule either. It has to do with omni.ja corruption, and if we have a corrupt omni.ja, we don't have any option other than to crash.

Comment 16

[Wayne Mery (:wsmwk)]

Are these in the same bucket?

• mozilla::dom::L10nOverlays::OverlayAttributes
• mozilla::dom::DocumentL10n_Binding::Wrap

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

maybe the latter, definitely not the former.

But it should go away after bug 1613705 lands.

Comment 18

[Zibi Braniecki [:zbraniecki][:gandalf]]

this seems fixed starting in 93.