You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Cliff Jansen (JIRA)" <ji...@apache.org> on 2012/10/02 21:59:07 UTC
[jira] [Updated] (QPID-4354) windows clients hang or fault on exit,
round N+1
[ https://issues.apache.org/jira/browse/QPID-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cliff Jansen updated QPID-4354:
-------------------------------
Description:
Windows clients continue to fault/hang on exit intermittently despite the fix in QPID-4330.
Additional traces attached. The qpid::log::Logger static destructor could be treated as in QPID-4330, but it is not clear how a similar intervention could be implemented for the _Fac_tidy atexit() routine which lives in Microsoft's own C++ runtime.
My unsubstantiated theory is that the IO threads continue servicing the last close operation, after exit() (or return from main()). Those IO threads can be decapitated arbitrarily by Windows, possibly holding locks or leaving data structures inconsistent (i.e. for malloc/free).
I would propose first confirming the theory in a private build with a new function that waits until all pending IO completion counts go to zero, and calling that function just before exit() in the test clients.
If the faults/hangs do indeed go away, then investigate if a correct fix would involve the use of such a function in Windows, or whether close() or a Connection's destructor should be made synchronous, or plan C.
> windows clients hang or fault on exit, round N+1
> ------------------------------------------------
>
> Key: QPID-4354
> URL: https://issues.apache.org/jira/browse/QPID-4354
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.18, 0.19
> Environment: Windows.
> Reporter: Cliff Jansen
> Assignee: Cliff Jansen
> Attachments: trace2.txt, trace3.txt
>
>
> Windows clients continue to fault/hang on exit intermittently despite the fix in QPID-4330.
> Additional traces attached. The qpid::log::Logger static destructor could be treated as in QPID-4330, but it is not clear how a similar intervention could be implemented for the _Fac_tidy atexit() routine which lives in Microsoft's own C++ runtime.
> My unsubstantiated theory is that the IO threads continue servicing the last close operation, after exit() (or return from main()). Those IO threads can be decapitated arbitrarily by Windows, possibly holding locks or leaving data structures inconsistent (i.e. for malloc/free).
> I would propose first confirming the theory in a private build with a new function that waits until all pending IO completion counts go to zero, and calling that function just before exit() in the test clients.
> If the faults/hangs do indeed go away, then investigate if a correct fix would involve the use of such a function in Windows, or whether close() or a Connection's destructor should be made synchronous, or plan C.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org