1345872 - Crash in mozalloc_abort | NS_DebugBreak | mozilla::ipc::ArrayLengthReadError

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-37ea984b-af82-4bfe-91a2-f765b2170309.
=============================================================

Seen while looking at Nighty crashes - this signature started using 20170304030205 while Nightly was in 54: http://bit.ly/2naasG6

Possible regression range based on Build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9732cd019a8b94c49a275661320c1b742635a3d6&tochange=80c06df83395314697d464f88f8daa98bf05465c

Currently in the last 7 days 79 crashes with 20 installations.

Comment 1

[Andrew McCreight [:mccr8]]

These were all happening in mozilla::dom::PContentChild::Read(nsTArray<mozilla::dom::GfxInfoFeatureStatus>*, IPC::Message const*, PickleIterator*) when I looked. The odd thing is, if the line numbers are correct, then this is a crash when reading the sentinel value. (I filed bug 1345897 to use a separate error message.)

The sentinels for the read and write matched up when I looked at SearchFox.

This message is sent very early in startup, so it is possible that this is the first sentinel check in content process startup. It is possible that this is happening because Firefox has updated, then the content process crashes, and we load the new version. This is supported by the fact that there are many installations per crash: if a user gets in that state, then the content process would crash immediately, then they'd click the button to reload, and they'd just crash again.

Maybe there is some lower level way to look at these crash reports to check if the parent and child process have the same buildid?

Comment 2

[Benjamin Smedberg]

Your theory is correct.

Evidence:
* buildid reported in crash metadata, which is from the parent process is 20170307030205
* http://ftp.mozilla.org/pub/firefox/nightly/2017/03/2017-03-07-03-02-05-mozilla-central/firefox-55.0a1.en-US.win32.txt shows that build was built from revision https://hg.mozilla.org/mozilla-central/rev/b7e42143bbbc9dc3e5c05bd1e93b6485ce1d0ad4
* the source links in the stack trace are from the minidump of the content process. They point to https://hg.mozilla.org/mozilla-central/annotate/58753259bfeb/xpcom/base/nsDebugImpl.cpp#l397
* http://ftp.mozilla.org/pub/firefox/nightly/2017/03/2017-03-08-03-02-07-mozilla-central/firefox-55.0a1.en-US.win32.txt shows that 58753259bfeb is from the next day's nightly

I'm a little surprised that it's *possible* to update Firefox while it's running like this, because of file locks. rstrong what would it take to make that impossible?

We should really have an explicit check that subprocesses match the parent buildID exactly. mccr8 that's probably worth filing as a bug all on its own, can you do that?

Comment 3

[Andrew McCreight [:mccr8]]

Filed bug 1345978.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This is probably bug 1112937 again. We really, really need to fix that bug!

Comment 5

[Robert Strong (they/them - no direct email)]

(In reply to Bill McCloskey (:billm) from comment #4)
> This is probably bug 1112937 again. We really, really need to fix that bug!

Yep

Comment 6

[Andrew McCreight [:mccr8]]

This should be "fixed" by detecting build mismatches on 55.