1277523 - Shutdown hang in CThreadInputMgr::PeekMessageW | mozilla::net::nsHttpConnectionMgr::Shutdown

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Kan-Ru Chen [:kanru] (UTC+9)]

This bug was filed from the Socorro interface and is 
report bp-8f601634-63dd-414e-81e9-e953d2160601.
=============================================================

https://crash-stats.mozilla.com/signature/?proto_signature=~nsHttpConnectionMgr%3A%3AShutdown&signature=shutdownhang%20%7C%20ntdll.dll%400x4bb7a&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1

I think the signature CThreadInputMgr::PeekMessageW in the call stack is called by WinUtils::PeekMessage in nsAppShell::ProcessNextNativeEvent; it doesn't mean the issue is related to input method management. Tentatively filed under the Networking: HTTP component. 

Masayuki, just in case, do you know if CThreadInputMgr::PeekMessageW can block?

Patrick, this crash is high in recent crash reports but I can't find any clue about what is causing the shutdown hang. I can't find the Socket Thread in the crash reports, maybe I'm looking at the wrong place. Maybe we could relax the condition by not requiring all sockets be closed or add some annotation so we know what nsHTTPConnectionMgr was waiting for?

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't know. TSF-aware applications have to use ITfMessagePump::PeekMessageW() instead of ::PeekMessageW(). If we find the STR, we can test with ::PeekMessageW() with setting |intl.tsf.enable| to false (restart required).

Comment 2

[Patrick McManus [:mcmanus]]

dragana, can you assess the next step on this one?

Comment 3

[Dragana Damjanovic [:dragana]]

Valentin, can you download some row dumps for this signature. 
Most interesting are for 49. Some of them have Sophos and something else with "..Life.." but not all of them. Find one without.
Thanks.


There was someone mentioning a bug to fix stacks, they are pretty broken.

Comment 4

[Kan-Ru Chen [:kanru] (UTC+9)]

My Windows-API-fu is weak but MSDN says PeekMessage:

During this call, the system delivers pending, nonqueued messages, that is, messages sent to windows owned by the calling thread using the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function.

PeekMessage may take a long time to process some nonqueued messages and then watch dog kicks in.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Hi Dragana, I looked at a few crash reports, and I don't see anything different in the stack than crash-stats is showing.
I have emailed a crash dump to you for https://crash-stats.mozilla.com/report/index/b9969843-cd29-4421-bc51-59dbe2160527#allthreads - it doesn't seem to have Sophos or *Life* present.

Comment 6

[Valentin Gosu [:valentin] (he/him)]

It might be worth mentioning that VS shows _pr_activeLock being NULL in _PR_NativeRunThread - line 419.

Comment 7

[Dragana Damjanovic [:dragana]]

This seems to be disappearing around 11th June

Comment 8

[Dragana Damjanovic [:dragana]]

there is only 2 crashes after 11th June. The last one is on 19th June.
Therefore i will close this bug.