1689628 - Crash in [@ mozilla::net::HttpChannelChild::Release]

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect, P3)

Description

[Sean Feng [:sefeng]]

Crash report: https://crash-stats.mozilla.org/report/index/bbb51eb6-3948-43d9-a790-a0d0d0210126

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll [thunk]: virtual unsigned long mozilla::net::HttpChannelChild::Release 
1 xul.dll nsCOMPtr_base::assign_from_qi xpcom/base/nsCOMPtr.cpp:46
2 xul.dll mozilla::dom::ScriptLoader::StartLoad dom/script/ScriptLoader.cpp:1548
3 xul.dll mozilla::dom::ScriptLoader::PreloadURI dom/script/ScriptLoader.cpp:4241
4 xul.dll nsHtml5SpeculativeLoad::Perform parser/html/nsHtml5SpeculativeLoad.cpp:61
5 xul.dll nsHtml5LoadFlusher::Run parser/html/nsHtml5StreamParser.cpp:191
6 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:146
7 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:741
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
9 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87

Honestly, I don't know if the crashes were legit. Maybe just caused by some bad memory bits? I filed it I see similar crashes from two different installations for this build 20210125093408

Comment 1

[Kershaw Chang [:kershaw]]

There is no crash in 85. Probably fixed by bug 1679908.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Still crashing; almost all wildptr crashes; low frequency (~2/week). re-triage.
One thing I wonder about here:

HttpChannelChild::Release() will dispatch to MainThread if it is released off-main-thread.... but it accesses and returns mRefCnt-1, which is not a threadsafe value. This means that the return value is effectively random, possibly including 0 - which makes me wonder if this is unsafe in some way (mostly I think if someone depended on the return value here. Since it's random, couldn't we just replace it with "return 1;"? If someone is depending on it, we should fix that -- or make it threadsafe.

In general, the refcnt logic in HttpChannelChild is ... complex, and unusual. While it comments on what it's doing, it doesn't include comments on why it is doing it.

Comment 3

[Greg Hess]

Most likely cause is someone else is trashing our memory.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Most likely the source is someone trashing our object (UAF write). We may want to fix the refcnt thing even if no one depends on it today

Comment 5

[Daniel Veditz [:dveditz]]

rated "moderate" based on frequency, maybe there some timing or coincidences involved that would make it harder to discover and weaponize. But we would rate this higher if we figure out a way to cause it or increase the frequency

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Moved the mRefCnt issue to another bug 1803148. Marking the remainder here as stalled

Comment 7

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

These are still trickling in slowly, however, we are trying to close unactionable stalled bugs, and this one doesn't seem to have a path forward.

Comment 8

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.