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)

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?

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

Hmmm, the patch from the only regression range's bug looks very unrelated.

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.

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?

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.

Close per comment 6.

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.

A Pernosco session is available here: https://pernos.co/debug/I9_64UHeiniRbiUCfZrTHA/index.html

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

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)

Setting regressed_by field after analyzing regression range found by bugmon.

Set release status flags based on info from the regressing bug 1641268

:pdahiya, since you are the author of the regressor, bug 1641268, could you take a look?
For more information, please visit auto_nag documentation.

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?

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.

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!

Set release status flags based on info from the regressing bug 1641268

For the time being I just remove the wrong regressor. Hopefully the bot will not add it again.