[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)
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)
Filed by: mkmelin [at] iki.fi
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=337152162&repo=comm-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SG7jeYk-T1CYNj33Nki8OA/runs/0/artifacts/public/logs/live_backing.log
Comment 1•4 years ago
|
||
Started after the merge, so something from https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=e2fb29057e4cb7cec500f1047e110dfa1ec0f901
Comment 2•4 years ago
|
||
Suspect: bug 1696158.
Comment 3•4 years ago
|
||
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)
Comment 4•4 years ago
|
||
[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: ??? (???:???)
Updated•4 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 8•4 years ago
|
||
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?
Comment 9•4 years ago
|
||
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
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 13•3 years ago
|
||
Assignee | ||
Comment 14•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/dc8885c340a9
Make sure all mailnews nsIChannel implementations have loadInfo set. r=mkmelin
Description
•