Assertion failure: parent (Parent doesn't exist in parent process), at src/dom/ipc/ContentParent.cpp:5729
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | fixed |
People
(Reporter: tsmith, Assigned: farre)
References
(Blocks 1 open bug, Regression)
Details
(4 keywords)
Attachments
(1 file)
168 bytes,
text/html
|
Details |
Reduced with m-c:
BuildID=20190620220631
SourceStamp=4cde299454c9851a32d555ce7004f2f69457ecb3
The fuzzers started hitting this on June 14th and have been hitting it frequently since.
The attached testcase can take a few moments to reproduce the issue.
Assertion failure: parent (Parent doesn't exist in parent process), at src/dom/ipc/ContentParent.cpp:5729
==31664==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7fb7c19fb308 bp 0x7ffd33725e50 sp 0x7ffd33725ca0 T0)
==31664==The signal is caused by a WRITE memory access.
==31664==Hint: address points to the zero page.
#0 0x7fb7c19fb307 in IsInPurpleBuffer src/obj-firefox/dist/include/nsISupportsImpl.h:257:15
#1 0x7fb7c19fb307 in decr<&NS_CycleCollectorSuspect3> src/obj-firefox/dist/include/nsISupportsImpl.h:229
#2 0x7fb7c19fb307 in Release src/obj-firefox/dist/include/mozilla/dom/BrowsingContextGroup.h:31
#3 0x7fb7c19fb307 in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:46
#4 0x7fb7c19fb307 in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:363
#5 0x7fb7c19fb307 in ~RefPtr src/obj-firefox/dist/include/mozilla/RefPtr.h:77
#6 0x7fb7c19fb307 in mozilla::dom::ContentParent::RecvAttachBrowsingContext(mozilla::dom::BrowsingContext::IPCInitializer&&) src/dom/ipc/ContentParent.cpp:5766
#7 0x7fb7b927c630 in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) src/obj-firefox/ipc/ipdl/PContentParent.cpp:10573:57
#8 0x7fb7b8eb3756 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) src/ipc/glue/MessageChannel.cpp:2158:25
#9 0x7fb7b8eae65b in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) src/ipc/glue/MessageChannel.cpp:2082:9
#10 0x7fb7b8eb0c17 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) src/ipc/glue/MessageChannel.cpp:1939:3
#11 0x7fb7b8eb19a7 in mozilla::ipc::MessageChannel::MessageTask::Run() src/ipc/glue/MessageChannel.cpp:1970:13
#12 0x7fb7b7a72861 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1225:14
#13 0x7fb7b7a7a634 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:486:10
#14 0x7fb7b8ebcb1f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:88:21
#15 0x7fb7b8d93a0e in RunInternal src/ipc/chromium/src/base/message_loop.cc:315:10
#16 0x7fb7b8d93a0e in RunHandler src/ipc/chromium/src/base/message_loop.cc:308
#17 0x7fb7b8d93a0e in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290
#18 0x7fb7c24d9c23 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27
#19 0x7fb7c67e3bc0 in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:276:30
#20 0x7fb7c6b238ba in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:4639:22
#21 0x7fb7c6b26124 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4778:8
#22 0x7fb7c6b27b19 in XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4859:21
#23 0x561ce53f4b14 in do_main src/browser/app/nsBrowserApp.cpp:213:22
#24 0x561ce53f4b14 in main src/browser/app/nsBrowserApp.cpp:295
Comment 1•5 years ago
|
||
$ ./mach file-info bugzilla-component dom/ipc/ContentParent.cpp
Core :: DOM: Content Processes
dom/ipc/ContentParent.cpp
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Interesting - this code is definitely doing something a touch fun with iframes. It seems we're adopting our document into our iframe repeatedly, and then triggering a reload.
The crash is happening here: https://searchfox.org/mozilla-central/rev/da14c413ef663eb1ba246799e94a240f81c42488/dom/ipc/ContentParent.cpp#5729 -- I'm guessing we're hitting a race condition where we're adopting the <iframe> element into the nested iframe while everything is being reloaded, so it's a BC lifecycle issue. Perhaps we're attempting to attach a BC as a child of a detached BC or similar.
:farre, any idea how this might be happening?
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 4•5 years ago
|
||
If this starts on June 14th it's probably bug 1555287. This has been backed out so let's keep an eye if the signature disappears.
Comment 5•5 years ago
|
||
Can you confirm if this is no longer seen since bug 1555287 was backed out and its new patch has been pushed to autoland today (should land soon)?
Reporter | ||
Comment 6•5 years ago
|
||
I can confirm the fuzzers are no longer hitting this issue. I will post an update if I see it again once bug 1555287 lands.
Comment 7•5 years ago
|
||
The priority flag is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
Tyson, can you confirm if this issue is no longer reproducible and this bug can be closed now?
Reporter | ||
Comment 9•5 years ago
|
||
This was last reported by the fuzzer on July 9th.
Comment 10•5 years ago
|
||
Is it worth trying to land the attached testcase as a crashtest?
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 11•4 years ago
|
||
I think it's hard to add this as a test since it's a reload in a loop, which makes it hard to "check" when it has succeeded, given that it doesn't crash.
Updated•4 years ago
|
Updated•2 years ago
|
Description
•