Closed
Bug 1277523
Opened 9 years ago
Closed 9 years ago
Shutdown hang in CThreadInputMgr::PeekMessageW | mozilla::net::nsHttpConnectionMgr::Shutdown
Categories
(Core :: Networking: HTTP, defect)
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)
Comment 1•9 years ago
|
||
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)
Comment 2•9 years ago
|
||
dragana, can you assess the next step on this one?
Assignee: nobody → dd.mozilla
Flags: needinfo?(mcmanus)
Whiteboard: [necko-active]
Assignee | ||
Comment 3•9 years ago
|
||
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)
Reporter | ||
Comment 4•9 years ago
|
||
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•9 years ago
|
||
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)
Comment 6•9 years ago
|
||
It might be worth mentioning that VS shows _pr_activeLock being NULL in _PR_NativeRunThread - line 419.
Assignee | ||
Comment 7•9 years ago
|
||
This seems to be disappearing around 11th June
Assignee | ||
Comment 8•9 years ago
|
||
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: 9 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•9 years ago
|
Resolution: FIXED → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•