Closed Bug 1822814 Opened 2 years ago Closed 10 months ago

Crash in [@ nsObserverService::EnsureValidCall | nsObserverService::NotifyObservers | mozilla::net::nsHttpHandler::NotifyObservers] called on TRR Background thread

Categories

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

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: valentin, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, Whiteboard: [necko-triaged])

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/52d54210-b024-49ef-94cc-d08270230316

MOZ_CRASH Reason: MOZ_CRASH(Using observer service off the main thread!)

Top 10 frames of crashing thread:

0  libxul.so  nsObserverService::EnsureValidCall const  xpcom/ds/nsObserverService.cpp:171
0  libxul.so  nsObserverService::NotifyObservers  xpcom/ds/nsObserverService.cpp:275
1  libxul.so  mozilla::net::nsHttpHandler::NotifyObservers  netwerk/protocol/http/nsHttpHandler.cpp:715
2  libxul.so  mozilla::net::nsHttpHandler::OnStopRequest  netwerk/protocol/http/nsHttpHandler.h:380
2  libxul.so  mozilla::net::HttpBaseChannel::DoNotifyListener  netwerk/protocol/http/HttpBaseChannel.cpp:4281
3  libxul.so  mozilla::net::HttpAsyncAborter<mozilla::net::nsHttpChannel>::HandleAsyncAbort  netwerk/protocol/http/HttpBaseChannel.h:1088
3  libxul.so  mozilla::net::nsHttpChannel::HandleAsyncAbort  netwerk/protocol/http/nsHttpChannel.cpp:3126
4  libxul.so  mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::net::nsHttpChannel, void   xpcom/threads/nsThreadUtils.h:1163
4  libxul.so  mozilla::detail::RunnableMethodArguments<>::apply<mozilla::net::nsHttpChannel, void   xpcom/threads/nsThreadUtils.h:1169
4  libxul.so  mozilla::detail::RunnableMethodImpl<mozilla::net::nsHttpChannel*, void   xpcom/threads/nsThreadUtils.h:1216

It seems we are using an nsHttpChannel implementation on the TRR thread.
I couldn't figure out exactly how that is happening. I was using OHTTP at the time, I think it's caused by bug 1815741 but I couldn't confirm yet (nor can I see the bug in the code)

I just realized I had network.trr.fetch_off_main_thread = false.
We should also check the pref value here - otherwise the cancellation would get dispatched to the TRR thread even for nsHttpChannel thus triggering an assertion.

Blocks: doh
Priority: P1 → P3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WORKSFORME

There's a large crash spike happening under this signature. Valentin, should we reopen this bug or is it a different crash?

Flags: needinfo?(valentin.gosu)

This is a different crash.
It seems FontFaceSetWorkerImpl::StartLoad is creating a channel and calling asyncOpen off main thread.
I assume this bug has existed for a while, but now a big website has done something with font workers?

Flags: needinfo?(valentin.gosu)

Looking at the URLs it must be Google Maps, I'm opening a separate bug, thanks!

QA Whiteboard: [qa-triaged]
QA Whiteboard: [qa-triaged]
You need to log in before you can comment on or make changes to this bug.