Investigate MOZ_RELEASE_ASSERT(pid != kInvalidProcessId) crashes
Categories
(Core :: IPC, defect)
Tracking
()
People
(Reporter: jstutte, Unassigned)
References
Details
There appear to be some crashes that are caused by MOZ_RELEASE_ASSERT(pid != kInvalidProcessId).
It seems those popped already up (see bug 1718067) and there might be nothing actionable here. The signatures I see in that query are all on OSX or Linux, apparently.
(FWIW, I arrived here through bug 1565903).
|
||
Comment 1•4 years ago
|
||
Half of the top 10 in that list doesn't appear to be properly symbolized so I don't think those will be actionable.
The second one on the list is [@ mozilla::dom::DOMSVGTransform::~DOMSVGTransform ] and the stacks don't make much sense: bp-7ec02454-4c1d-4e4d-937b-adc130210717
The first frame looks like nonsense. The second frame is some IOUtils thing that might be related, but I'm not sure what runnable or IPC that file actually uses.
The other vaguely reasonable looking signature is one involving IndexCountRequestOp::DoDatabaseWork: bp-346afadf-7f68-4ccb-a5d3-5551f0210716
but I'm not really sure what is going on there either. The second frame looks similar to the weird IOUtils runnable from the SVG crash. I'm not sure how the top frame does IPC there.
|
||
Comment 2•4 years ago
|
||
There's a lot of libxul.so (deleted), which I believe is what happens if an update happens underneath a running Firefox on Linux. That would also get us into some process-launching-related error paths that we don't really test.
|
||
Comment 3•4 years ago
|
||
It appears that the signature of these crashes has changed in recent versions, as the assertion was moved and the kInvalidProcessId constant was renamed. A more accurate search today may be this.
|
|
||
Comment 4•4 years ago
|
||
The bug linked by :jstutte (bug 1649857) appears to be tracking the new signatures here.
|
|
||
Comment 5•4 years ago
|
||
Closing as the individual crashes are being tracked in their own bug (see comment 4)
Description
•