[
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: [email protected]
For additional commands, e-mail: [email protected]
