1694628 - Assertion failure: mEvictionQSize, at /builds/worker/checkouts/gecko/netwerk/dns/nsHostResolver.cpp:1364

Status: RESOLVED DUPLICATE of bug 1688092

(Core :: Networking: DNS, defect, P2)

Description

[Kershaw Chang [:kershaw]]

I accidentally hit this assertion when running test_odoh.js on try.

stack trace:

[task 2021-02-23T20:29:51.121Z] 20:29:51     INFO -  PID 27038 | Assertion failure: mEvictionQSize, at /builds/worker/checkouts/gecko/netwerk/dns/nsHostResolver.cpp:1364
[task 2021-02-23T20:29:51.121Z] 20:29:51     INFO -  PID 27038 | #01: nsHostResolver::NativeLookup(nsHostRecord*) [netwerk/dns/nsHostResolver.cpp:1489]
[task 2021-02-23T20:29:51.121Z] 20:29:51     INFO -  PID 27038 | #02: nsHostResolver::CompleteLookup(nsHostRecord*, nsresult, mozilla::net::AddrInfo*, bool, nsTSubstring<char> const&, nsHostRecord::TRRSkippedReason, mozilla::net::TRR*) [netwerk/dns/nsHostResolver.cpp:1959]
[task 2021-02-23T20:29:51.121Z] 20:29:51     INFO -  (xpcshell/head.js) | test run_next_test 7 finished (2)
[task 2021-02-23T20:29:51.121Z] 20:29:51     INFO -  PID 27038 | #03: mozilla::net::TRRQuery::CompleteLookup(nsHostRecord*, nsresult, mozilla::net::AddrInfo*, bool, nsTSubstring<char> const&, nsHostRecord::TRRSkippedReason, mozilla::net::TRR*) [netwerk/dns/TRRQuery.cpp:276]
[task 2021-02-23T20:29:51.122Z] 20:29:51     INFO -  PID 27038 | #04: mozilla::net::TRR::FailData(nsresult) [netwerk/dns/TRR.cpp:751]
[task 2021-02-23T20:29:51.122Z] 20:29:51     INFO -  PID 27038 | #05: mozilla::net::TRR::Run() [netwerk/dns/TRR.cpp:81]
[task 2021-02-23T20:29:51.122Z] 20:29:51     INFO -  PID 27038 | #06: mozilla::net::ODoH::Run() [netwerk/dns/ODoH.cpp:44]
[task 2021-02-23T20:29:51.122Z] 20:29:51     INFO -  PID 27038 | #07: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1153]
[task 2021-02-23T20:29:51.125Z] 20:29:51     INFO -  PID 27038 | #08: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:548]
[task 2021-02-23T20:29:51.126Z] 20:29:51     INFO -  PID 27038 | #09: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:303]
[task 2021-02-23T20:29:51.126Z] 20:29:51     INFO -  PID 27038 | #10: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:335]
[task 2021-02-23T20:29:51.127Z] 20:29:51     INFO -  PID 27038 | #11: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:311]
[task 2021-02-23T20:29:51.127Z] 20:29:51     INFO -  PID 27038 | #12: nsThread::ThreadFunc(void*) [xpcom/threads/nsThread.cpp:393]
[task 2021-02-23T20:29:51.143Z] 20:29:51     INFO -  PID 27038 | #13: _pt_root [nsprpub/pr/src/pthreads/ptthread.c:204]
[task 2021-02-23T20:29:51.144Z] 20:29:51     INFO -  PID 27038 | #14: ??? [/lib/x86_64-linux-gnu/libpthread.so.0 + 0x76db]
[task 2021-02-23T20:29:51.144Z] 20:29:51     INFO -  PID 27038 | #15: clone [/lib/x86_64-linux-gnu/libc.so.6 + 0x121a3f]
[task 2021-02-23T20:29:51.145Z] 20:29:51     INFO -  PID 27038 | #16: ??? (???:???)

Comment 1

[Kershaw Chang [:kershaw]]

Duplicate this to bug 1688092, since this will be fixed by the patch D106415.

This bug also provide a possible explanation why the record is in the high queue.
Imagine the code path below:

1. On main thread, mTrrA is assigned here.
2. On main thread, exit the scope of this lock.
3. On TRR thread, TRRQuery::CompleteLookup() is called. mTrrA is set to null here and mTrrAAAA is not assigned yet. At this point, pendingARequest and pendingAAAARequest are false, so mHostResolver::CompleteLookup() will be called.
4. In mHostResolver::CompleteLookup(), NativeLookup() is called here, so the record is put in the high queue.
5. On main thread, mTrrAAAA is assigned here.
6. Like step 3 and 4, NativeLookup() is called again for mTrrAAAA and we hit this assertion.