Closed Bug 1789366 Opened 2 years ago Closed 1 year ago

Crash in [@ mozilla::ipc::PUtilityProcessParent::OtherPid]

Categories

(Core :: IPC, defect)

Unspecified
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: gsvelto, Assigned: gerard-majax)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/8632ee60-070b-49e5-bf56-64a850220902

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::PUtilityProcessParent::OtherPid const ipc/ipdl/PUtilityProcessParent.cpp:53
1 xul.dll mozilla::MozPromise<bool, nsresult, 0>::ThenValue<`lambda at /builds/worker/checkouts/gecko/ipc/glue/UtilityProcessManager.cpp:275:11', `lambda at /builds/worker/checkouts/gecko/ipc/glue/UtilityProcessManager.cpp:304:11'>::DoResolveOrRejectInternal xpcom/threads/MozPromise.h:861
2 xul.dll mozilla::MozPromise<bool, mozilla::ipc::ResponseRejectReason, 1>::ThenValueBase::ResolveOrRejectRunnable::Run xpcom/threads/MozPromise.h:487
3 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:851
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1205
5 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
6 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:374
7 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:356
8 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:150
9 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:614

It seems like we're accessing a NULL object within the lambda function, not sure where to file this, Alexandre can you find an appropriate component?

Flags: needinfo?(lissyx+mozillians)

Oh, it is something I did hit on bug 1788596

Flags: needinfo?(lissyx+mozillians)
Assignee: nobody → lissyx+mozillians
Component: General → IPC

I clearly was reproducing that on linux, but it seems there might be other ways to reproduce on osx and windows:

OS: Windows → All
Crash Signature: [@ mozilla::ipc::PUtilityProcessParent::OtherPid] → [@ mozilla::ipc::IProtocol::ToplevelProtocol] [@ mozilla::ipc::PUtilityProcessParent::OtherPid]

Is this on your radar? I see the volume is climbing

Crash Signature: [@ mozilla::ipc::IProtocol::ToplevelProtocol] [@ mozilla::ipc::PUtilityProcessParent::OtherPid] → [@ mozilla::ipc::PUtilityProcessParent::OtherPid]
Flags: needinfo?(lissyx+mozillians)

I've fixed several with https://bugzilla.mozilla.org/show_bug.cgi?id=1788596, so I hope the increase is not on nightly

Flags: needinfo?(lissyx+mozillians)

https://phabricator.services.mozilla.com/D156847 and https://phabricator.services.mozilla.com/D156484 are the ones that were fixing crash with the same stack, maybe we can request uplift?

Yeah nevermind, this looks already fixed on nightly and the release volume isn't really high, we can let the fix ride the trains.

Crash Signature: [@ mozilla::ipc::PUtilityProcessParent::OtherPid] → [@ mozilla::ipc::IProtocol::ToplevelProtocol ] [@ mozilla::ipc::PUtilityProcessParent::OtherPid]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Gabriele, now I cannot see any signature matching on Utility instances, are we safe and can we mark this as FIXED ?

Flags: needinfo?(gsvelto)

Yes, we're good!

Flags: needinfo?(gsvelto)
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.