qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Jansen (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (QPID-4330) windows clients hang or fault on exit (static destructors)
Date Tue, 02 Oct 2012 05:27:08 GMT

     [ https://issues.apache.org/jira/browse/QPID-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Cliff Jansen resolved QPID-4330.
--------------------------------

    Resolution: Fixed

fixed r1392093.  See

https://reviews.apache.org/r/7179/
                
> windows clients hang or fault on exit (static destructors)
> ----------------------------------------------------------
>
>                 Key: QPID-4330
>                 URL: https://issues.apache.org/jira/browse/QPID-4330
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.16, 0.18
>         Environment: Windows
>            Reporter: Cliff Jansen
>            Assignee: Cliff Jansen
>             Fix For: 0.19
>
>
> Windows clients occasionally fail to terminate cleanly after exit() or return from main().
 I have examined a large number of stack traces, mostly gibberish presumably from rogue memory
writes some time in the past.  Two refreshingly clear traces showed failure when direct or
indirect threading calls were made from inside a static destructor: ~IOThread and ~WinSockSetup.
> If a DLL (shared object) is winding up due to the library being unloaded (FreeLibrary),
the DLL code has an obligation to clean up resources that could leak, and since the process
hasn't exited, existing threads live on and threading primitives are trustworthy.   In this
case the Windows library may (and should) follow the Linux clean up logic in its static destructors.
> If the DLL is winding up due to exit() (or return from main()), it is undefined how quickly
other threads will be forcefully terminated.  Locks may be held indefinitely or falsely released
(changed in the Vista time frame).  In this case, any fancy footwork is dangerous.  The best
course of action is to let the OS clean up things it would anyway, i.e. do nothing if possible.

--
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


Mime
View raw message