Closed Bug 1706387 Opened 4 years ago Closed 3 years ago

[tb debug perma] Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) && result, at /builds/worker/workspace/obj-build/dist/include/nsIChannel.h:135

Categories

(MailNews Core :: Backend, defect, P5)

Tracking

(thunderbird_esr78 unaffected, thunderbird89 unaffected)

RESOLVED FIXED
90 Branch
Tracking Status
thunderbird_esr78 --- unaffected
thunderbird89 --- unaffected

People

(Reporter: intermittent-bug-filer, Assigned: benc)

References

(Regression)

Details

(Keywords: assertion, intermittent-failure, Whiteboard: [stockwell disable-recommended])

Attachments

(1 file)

Looks like that is it: try run with those changesets backed out: https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=eFixGfqfSM6sZqCkCaHFJA.0&revision=11d23084ec782e962783632e7b0d682302e59ced
(hg export --git bcab4e2d5d6bf39823cf7c1b02bc3e4853f44ad5:00fce1d7c7853bb350dc771f23a216ca9622c7eb | patch -R -p1)

From here: https://searchfox.org/mozilla-central/rev/9b430bb1a11d7152cab2af4574f451ffb906b052/docshell/base/nsDocShell.cpp#13606

[task 2021-04-20T12:35:39.633Z] 12:35:39     INFO - GECKO(1536) | Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) && result, at /builds/worker/workspace/obj-build/dist/include/nsIChannel.h:135
[task 2021-04-20T12:35:39.654Z] 12:35:39     INFO -  Initializing stack-fixing for the first stack frame, this may take a while...
[task 2021-04-20T12:35:45.745Z] 12:35:45     INFO - GECKO(1536) | #01: nsDocShell::RecordSingleChannelId() [docshell/base/nsDocShell.cpp:13606]
[task 2021-04-20T12:35:45.746Z] 12:35:45     INFO - GECKO(1536) | #02: nsDocShell::OnStartRequest(nsIRequest*) [docshell/base/nsDocShell.cpp:13675]
[task 2021-04-20T12:35:45.747Z] 12:35:45     INFO - GECKO(1536) | #03: mozilla::net::nsLoadGroup::AddRequest(nsIRequest*, nsISupports*) [netwerk/base/nsLoadGroup.cpp:489]
[task 2021-04-20T12:35:45.747Z] 12:35:45     INFO - GECKO(1536) | #04: nsMsgProtocol::OnStartRequest(nsIRequest*) [comm/mailnews/base/src/nsMsgProtocol.cpp:312]
[task 2021-04-20T12:35:45.748Z] 12:35:45     INFO - GECKO(1536) | #05: nsInputStreamPump::OnStateStart() [netwerk/base/nsInputStreamPump.cpp:481]
[task 2021-04-20T12:35:45.748Z] 12:35:45     INFO - GECKO(1536) | #06: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) [netwerk/base/nsInputStreamPump.cpp:390]
[task 2021-04-20T12:35:45.751Z] 12:35:45     INFO - GECKO(1536) | #07: {virtual override thunk({offset(-8)}, nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*))} [/builds/worker/workspace/build/application/thunderbird/libxul.so + 0x45e2541]
[task 2021-04-20T12:35:45.752Z] 12:35:45     INFO - GECKO(1536) | #08: mozilla::SlicedInputStream::OnInputStreamReady(nsIAsyncInputStream*) [xpcom/io/SlicedInputStream.cpp:416]
[task 2021-04-20T12:35:45.753Z] 12:35:45     INFO - GECKO(1536) | #09: nsInputStreamReadyEvent::Run() [xpcom/io/nsStreamUtils.cpp:96]
[task 2021-04-20T12:35:45.754Z] 12:35:45     INFO - GECKO(1536) | #10: mozilla::RunnableTask::Run() [xpcom/threads/TaskController.cpp:474]
[task 2021-04-20T12:35:45.754Z] 12:35:45     INFO - GECKO(1536) | #11: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:757]
[task 2021-04-20T12:35:45.754Z] 12:35:45     INFO - GECKO(1536) | #12: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:612]
[task 2021-04-20T12:35:45.755Z] 12:35:45     INFO - GECKO(1536) | #13: mozilla::TaskController::ProcessPendingMTTask(bool) [xpcom/threads/TaskController.cpp:396]
[task 2021-04-20T12:35:45.755Z] 12:35:45     INFO - GECKO(1536) | #14: mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_1>::Run() [xpcom/threads/nsThreadUtils.h:535]
[task 2021-04-20T12:35:45.756Z] 12:35:45     INFO - GECKO(1536) | #15: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1163]
[task 2021-04-20T12:35:45.756Z] 12:35:45     INFO - GECKO(1536) | #16: ??? [/builds/worker/workspace/build/application/thunderbird/libxul.so + 0x44cbe86]
[task 2021-04-20T12:35:45.756Z] 12:35:45     INFO - GECKO(1536) | #17: CallMethodHelper::Call() [js/xpconnect/src/XPCWrappedNative.cpp:1176]
[task 2021-04-20T12:35:45.756Z] 12:35:45     INFO - GECKO(1536) | #18: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) [js/xpconnect/src/XPCWrappedNative.cpp:1142]
[task 2021-04-20T12:35:45.757Z] 12:35:45     INFO - GECKO(1536) | #19: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) [js/xpconnect/src/XPCWrappedNativeJSOps.cpp:925]
[task 2021-04-20T12:35:45.757Z] 12:35:45     INFO - GECKO(1536) | #20: ??? (???:???)
Flags: needinfo?(peterv)
Regressed by: 1696158
Summary: Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) && result, at /builds/worker/workspace/obj-build/dist/include/nsIChannel.h:135 → [tb debug perma] Assertion failure: ((bool)(__builtin_expect(!!(!NS_FAILED_impl(rv)), 1))) && result, at /builds/worker/workspace/obj-build/dist/include/nsIChannel.h:135

This means that there's a channel that returns an error from GetLoadInfo or returns null from GetLoadInfo. Since bug 1528677 we assume that that doesn't happen. Maybe a mailnews channel doesn't follow that?

Flags: needinfo?(peterv)

Yes, mailnews channels don't have a real loadinfo.

Ben, could we add real loadinfos?
The crash is due to https://hg.mozilla.org/mozilla-central/rev/4dc2eda2bcf84d2a1566be7964673e4d725a0ad7#l1.59

Assignee: nobody → benc

In that patch, I've gone through and added in loadInfo to all the places I could find where it might have gone unset. It also adds a few MOZ_ASSERT()s to catch missing loadInfos during channel setup, so we can actually get a useful call stack (previously it'd assert later on, and it wasn't obvious which concrete channel object was responsible).
Hopefully this'll sort it out...

Passes unit tests locally, and I kicked off a try run here: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=03869ca2dbb32fa0c381ec106751957dc7e7f8f9

A couple of further notes:

It's a little tricky as we've got quite a lot of nsIChannel-abuse going on ;-) A lot of the time our nsIChannel-derived objects aren't really used as channels (instead we have LoadUrl() to kick things off). There are also a few cases where our objects are re-used for multiple requests, which kind of tramples all over the standard nsIChannel life cycle. And finally, there's the IMAP usage, where there are connection objects and mock channels and they are kind of interchangable and it's a bit messy.

The loadInfo objects I added are just cargo-culted from other existing uses. I don't entirely understand how the loadInfo is used, and certainly not in the context of TB - it's a somewhat browser-centric thing. So I think at some point it'd be good to do a bit of an audit on all our loadInfo use and see if we can improve it.

Status: NEW → ASSIGNED
Target Milestone: --- → 90 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/dc8885c340a9
Make sure all mailnews nsIChannel implementations have loadInfo set. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: