Closed Bug 1377086 Opened 7 years ago Closed 2 years ago

Crash in [@ mozilla::ProfilerParent::CreateForProcess ]

Categories

(Core :: IPC, defect, P3)

Product:
Core
Component:
IPC
Version:
56 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox60 --- affected
firefox65 --- affected

People

(Reporter: jan, Unassigned)

References

Details

(Keywords: nightly-community, Whiteboard: qa-not-actionable)

Crash Data

bp-42f9be68-33b7-4a65-bac1-506ae0170629

I just opened many tabs and got a browser crash.
When Nightly restarted and I clicked on "restore session", the UI immediately has restored that many tabs, but...it freezed. There was an IndexedDB process that used the most RAM of all processes, but definitely not over 1 GB (don't remember how much exactly).

dom.ipc.processCount;100
Nightly didn't use much of my 16 GB RAM (+16 GB swap). Max. 4 GB I think.
No webrender/webrendest/stylo enabled.
Crash Signature: [@ mozilla::ProfilerParent::CreateForProcess ]
Keywords: nightly-community
Priority: -- → P3
I hit this twice when restarting Firefox after a crash:
https://crash-stats.mozilla.com/report/index/26263210-021d-47d5-bff3-ce65f0171206
https://crash-stats.mozilla.com/report/index/d0012765-b051-4237-b38f-ac5c40171206

One of those is missing a thread list so it has a bad signature, but the MOZ_CRASH is the same. Firefox crashed on startup, I don't recall if the browser UI was visible or not.
[Tracking Requested - why for this release]:

Got this after the update to Nightly 65 on Mac OS Siera
https://crash-stats.mozilla.com/report/index/6cdf2546-4d5c-465a-91eb-642140181024#tab-details
status-firefox65: --- → affected
It looks like there was an attempt to add more information to the crash report[1], left over from bug 1293580, but it's a no-op except on Mac[2].  (Also, despite the name "Errno", that's an nsresult.)

The cause in this case might be fd exhaustion, and off the top of my head I can't think of anything besides fd exhaustion that would cause this to fail on Unix, but there's no direct evidence for or against it.  (Also, I raised the fd limit a while back, so it should be harder to run out, even if we're transiently opening a ton of files at once during startup for some reason.)


[1] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/ipc/glue/ProtocolUtils.h#952-953
[2] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/ipc/glue/ProtocolUtils.h#932-933
See Also: → 1293580

I just did a try push that runs more wpt tests in a single invocation of the browser, and I started getting this crash in the (rather large) referrer-policy/gen/ directory, but in different tests each time. See wpt 4 in https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=290376516&revision=978d97aa1c0920660a6536a2e0b31eed72aa27e5

This is still happening. Example: https://crash-stats.mozilla.org/report/index/fe4ca17c-43fe-4df7-a260-a84f80210213
This particular report is from macOS, so in theory the report should contain an "IpcCreateEndpointsNsresult" annotation. However, I don't see it in the report. Is it considered "protected data"?

In that report, IpcCreateEndpointsNsresult is -2141126655 and IpcCreatePipeSocketPairErrno is 23.

and yes, it is under protected data in the report.

(In reply to Andrew McCreight [:mccr8] from comment #8)

In that report, IpcCreateEndpointsNsresult is -2141126655

That's NS_ERROR_TRANSPORT_INIT ((0x80610001 | 0) == -2141126655).

(In reply to Andrew McCreight [:mccr8] from comment #8)

and IpcCreatePipeSocketPairErrno is 23.

#define ENFILE          23              /* Too many open files in system */

Ok, looks like it is indeed fd exhaustion.

The Windows crashes look unrelated: a null pointer access somewhere in ProfilerParent::Init (but it's not clear where, because crash reports don't handle inlining correctly).

The other crashes — mostly Mac, a few Linux — are all the same MOZ_CRASH.

Reopening bug since there are crash reports in the last 6 months.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Whiteboard: qa-not-actionable

The underlying cause here might be different per platform, i.e. incidence on Linux might drop after the above fix.

This crash was previously caused by failure to create a pipe for an IPC channel, but since the channel multiplexing work that error path has been removed, so this will never be hit in newer code.

Status: REOPENED → RESOLVED
Closed: 3 years ago → 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.