Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Could not get DocShell from mFrameLoader?), at /builds/worker/checkouts/gecko/dom/base/nsObjectLoadingContent.cpp:550
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: tsmith, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:bisected,confirmed])
Attachments
(1 file, 1 obsolete file)
4.35 KB,
application/x-zip-compressed
|
Details |
Found while fuzzing (--enable-debug --enable-fuzzing)
Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Could not get DocShell from mFrameLoader?), at src/dom/base/nsObjectLoadingContent.cpp:550
#0 0x7f34dc045157 in nsObjectLoadingContent::SetupDocShell(nsIURI*) src/dom/base/nsObjectLoadingContent.cpp:550:9
#1 0x7f34dc04af73 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) src/dom/base/nsObjectLoadingContent.cpp:2176:40
#2 0x7f34dc04a1ac in nsObjectLoadingContent::OnStartRequest(nsIRequest*) src/dom/base/nsObjectLoadingContent.cpp:1044:10
#3 0x7f34dab02ef2 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) src/netwerk/protocol/http/HttpChannelChild.cpp:568:20
#4 0x7f34dab02b3b in mozilla::net::HttpChannelChild::OnStartRequest(mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::HttpChannelOnStartRequestArgs const&) src/netwerk/protocol/http/HttpChannelChild.cpp:499:3
#5 0x7f34daccd2bb in mozilla::net::ChannelEventQueue::FlushQueue() src/netwerk/ipc/ChannelEventQueue.cpp:90:12
#6 0x7f34dad01c59 in MaybeFlushQueue /builds/worker/workspace/obj-build/dist/include/mozilla/net/ChannelEventQueue.h:330:5
#7 0x7f34dad01c59 in CompleteResume /builds/worker/workspace/obj-build/dist/include/mozilla/net/ChannelEventQueue.h:309:5
#8 0x7f34dad01c59 in mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() src/netwerk/ipc/ChannelEventQueue.cpp:148:17
#9 0x7f34da540f4f in mozilla::RunnableTask::Run() src/xpcom/threads/TaskController.cpp:450:16
#10 0x7f34da53f5ba in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:720:26
#11 0x7f34da53e664 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) src/xpcom/threads/TaskController.cpp:579:15
#12 0x7f34da53e817 in mozilla::TaskController::ProcessPendingMTTask(bool) src/xpcom/threads/TaskController.cpp:373:36
#13 0x7f34da544899 in operator() src/xpcom/threads/TaskController.cpp:123:37
#14 0x7f34da544899 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_4>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:577:5
#15 0x7f34da555da7 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1194:14
#16 0x7f34da55be4a in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:513:10
#17 0x7f34dae5a3c4 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:109:5
#18 0x7f34dadc7753 in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:334:10
#19 0x7f34dadc766d in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
#20 0x7f34dadc766d in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
#21 0x7f34deaf1868 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27
#22 0x7f34e02efd03 in XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:913:20
#23 0x7f34dae5b1d9 in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:237:9
#24 0x7f34dadc7753 in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:334:10
#25 0x7f34dadc766d in RunHandler src/ipc/chromium/src/base/message_loop.cc:327:3
#26 0x7f34dadc766d in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:309:3
#27 0x7f34e02ef8e8 in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:744:34
#28 0x55ed99055a67 in content_process_main src/browser/app/../../ipc/contentproc/plugin-container.cpp:56:28
#29 0x55ed99055a67 in main src/browser/app/nsBrowserApp.cpp:304:18
#30 0x7f34ef5ea0b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16
#31 0x55ed99033819 in _start (/home/worker/builds/m-c-20201123095316-fuzzing-debug/firefox-bin+0x14819)
Comment 1•4 years ago
|
||
From nsObjectLoadingContent::SetupDocShell
it seems, that this case is handled properly in release (at least at this function's level).
But it would be interesting to see the state the browser was in while this happens. This comment suspects, that mFrameLoader->GetDocShell(result);
can return null if we are in an ongoing tear down. If so, we probably just should handle this error gracefully also in debug mode.
Tyson, can you provide a pernosco session here?
Comment 2•4 years ago
|
||
Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20201126212448-3636cdf0b487.
The bug appears to have been introduced in the following build range:
Start: 8d8372333cb931781c0443e3d0f374ade0519521 (20200529083550)
End: 2b61435dd03ee8646c61f777010bffd5e25ce36f (20200529083646)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8d8372333cb931781c0443e3d0f374ade0519521&tochange=2b61435dd03ee8646c61f777010bffd5e25ce36f
Comment 3•4 years ago
|
||
Hmmm, the patch from the only regression range's bug looks very unrelated.
Reporter | ||
Comment 4•4 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/6P3yo52Dh_VSygsFD4ppjw/index.html
Note: The attached test case would not reproduce under rr so an alternative test case was used.
Comment 5•4 years ago
•
|
||
The following sequence in the pernosco trace
[Child 5536, Main Thread] WARNING: NS_ENSURE_TRUE(browserChrome) failed: file /home/twsmith/code/mozilla-central/docshell/base/nsDocShell.cpp:12095
[Child 5536, Main Thread] WARNING: '!newWindow', file /home/twsmith/code/mozilla-central/dom/base/nsFrameLoader.cpp:2177
[Child 5536, Main Thread] WARNING: Something wrong when creating the docshell for a frameloader!: file /home/twsmith/code/mozilla-central/dom/base/nsFrameLoader.cpp:2179
points me to bug 472312 looking at this comment. Any memories of what we did there 12 years ago?
Comment 6•3 years ago
|
||
Bugmon Analysis
The bug appears to have been fixed in the following build range:
Start: 791ad465a0c8344f38d54f0a226860fc26cfe540 (20210218041606)
End: 7864080034f24964557019189060107cd4eecd61 (20210218005317)
Pushlog: https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=791ad465a0c8344f38d54f0a226860fc26cfe540&tochange=7864080034f24964557019189060107cd4eecd61
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
Comment 7•3 years ago
|
||
Close per comment 6.
Reporter | ||
Comment 8•3 years ago
|
||
The attached testcase no longer reproduces the issue but fuzzers have found new testcases recently. I will attach an updated testcase once reduction is complete.
Reporter | ||
Comment 9•3 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/I9_64UHeiniRbiUCfZrTHA/index.html
Reporter | ||
Comment 10•3 years ago
|
||
Reporter | ||
Comment 11•3 years ago
|
||
To reproduce via Grizzly Replay:
$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch -d --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip --xvfb --repeat 10
Reporter | ||
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220530140717-87e39a7da999.
Unable to bisect testcase (Testcase reproduces on start build!):
Start: 391dbe0ceb290de3c1a6989aab62e602e55f176c (20210601032903)
End: 391dbe0ceb290de3c1a6989aab62e602e55f176c (20210601032903)
BuildFlags: BuildFlags(asan=False, tsan=False, debug=True, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False)
Comment 13•2 years ago
|
||
Setting regressed_by field after analyzing regression range found by bugmon.
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Set release status flags based on info from the regressing bug 1641268
Comment 15•2 years ago
|
||
:pdahiya, since you are the author of the regressor, bug 1641268, could you take a look?
For more information, please visit auto_nag documentation.
Comment 16•2 years ago
|
||
Hi Jason, Marco,
it seems we have a problem with the release mgmt bot if we have two bisection ranges on the same bug. In fact, the first test case had one (comment 6), the second does not (comment 12). I assume in future it would be better to file a new bug for each testcase?
Comment 17•2 years ago
|
||
If they are exposing two different bugs, I'd say it would be better to file a new bug for each testcase.
If they are exposing the same bug, then I guess the regression ranges should be the same.
Comment 18•2 years ago
•
|
||
Bug marked as regressing was a UI fix in Fx78, Is release mgmt bot correct in identifying regression range here. If yes, can you please share more details on error and how to replicate thanks!
Updated•2 years ago
|
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Set release status flags based on info from the regressing bug 1641268
Updated•2 years ago
|
Comment 20•2 years ago
|
||
For the time being I just remove the wrong regressor. Hopefully the bot will not add it again.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 21•1 year ago
|
||
Unable to reproduce bug 1679478 using build mozilla-central 20221015212605-c9ad12757bb5. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
Description
•