Closed Bug 1277523 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Networking: HTTP, defect)

Unspecified
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kanru, Assigned: dragana)

Details

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

Crash Data

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?
Flags: needinfo?(mcmanus)
Flags: needinfo?(masayuki)
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).
Flags: needinfo?(masayuki)
dragana, can you assess the next step on this one?
Assignee: nobody → dd.mozilla
Flags: needinfo?(mcmanus)
Whiteboard: [necko-active]
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.
Flags: needinfo?(valentin.gosu)
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.
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.
Flags: needinfo?(valentin.gosu)
It might be worth mentioning that VS shows _pr_activeLock being NULL in _PR_NativeRunThread - line 419.
This seems to be disappearing around 11th June
there is only 2 crashes after 11th June. The last one is on 19th June.
Therefore i will close this bug.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.