qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stitcher (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-1868) Implicit TLS variables in AsyncIO can cause access violation when dynamically loading qpidcommon and qpidclient DLLs
Date Thu, 21 May 2009 22:07:45 GMT

    [ https://issues.apache.org/jira/browse/QPID-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711841#action_12711841
] 

Andrew Stitcher commented on QPID-1868:
---------------------------------------

This is a good direction, but please don't introduce boost::thread related stuff directly
into the code, it should be abstracted in the platform specific area. The Unix ports do not
use much in the way of boost libraries and I'm trying to reduce the dependencies in the application
code not increase it. This is because boost library dependencies are a packaging nightmare,
as boost doesn't maintain their previous releases at all. I'm happy for the individual ports
to rely on it if they like though as this issue may be different on Windows etc.

I suppose we need a "proper" way to do portable thread local vars so we'll need to introduce
an abstraction or at least an indirection in  qpid/sys.


> Implicit TLS variables in AsyncIO can cause access violation when dynamically loading
qpidcommon and qpidclient DLLs
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-1868
>                 URL: https://issues.apache.org/jira/browse/QPID-1868
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.5
>         Environment: Windows XP w/SP3
> Visual Studio 2005
>            Reporter: David Rennalls
>         Attachments: AsyncIO_TLS.patch, patch.txt
>
>
> src/qpid/sys/windows/AsynchIO.cpp is using some implicit thread local storage variables.
If the qpid DLLs are dynamically loaded (or another DLL that statically links in qpid) no
space will be allocated for the TLS data. So if client code tries to access one of the TLS
variables defined in AsyncIO.cpp it will get an access violation. Taken from [1]...
> "..If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause
a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes
system failure whenever the code references the nonlocal __declspec( thread ) data. Because
the global variable space for a thread is allocated at run time, the size of this space is
based on a calculation of the requirements of the application plus the requirements of all
of the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend
this space to allow for the thread local variables declared with __declspec( thread ). Use
the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with
LoadLibrary..."
> ...[2] also warns against this..
> "Windows Server 2003 and Windows XP:  The Visual C++ compiler supports a syntax that
enables you to declare thread-local variables: _declspec(thread). If you use this syntax in
a DLL, you will not be able to load the DLL explicitly using LoadLibrary on versions of Windows
prior to Windows Vista. If your DLL will be loaded explicitly, you must use the thread local
storage functions instead of _declspec(thread)."
> I ran into this when my DLL that links in qpid client and common libs statically is loaded
dynamically by a python wrapper, the first access to the one of the TLS variables cause a
crash. For reference , [3] (part 1 of 8) has a good overview of TLS on Windows, and implicit
vs explicit TLS
> [1] http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx - Rules and Limitations
for TLS
> [2] http://msdn.microsoft.com/en-us/library/ms684175.aspx - LoadLibrary function
> [3] http://www.nynaeve.net/?p=180 - Thread Local Storage, part 1: Overview

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message