I ran into the same TLS issue just last week, and made the following change in
ManagementObject.cpp in the 0.5-release branch to get it working in the short
term.
Index: ManagementObject.cpp
===================================================================
--- ManagementObject.cpp (revision 777221)
+++ ManagementObject.cpp (working copy)
@@ -172,12 +172,12 @@
void ManagementObject::setReference(ObjectId) {}
int ManagementObject::getThreadIndex() {
- static QPID_TSS int thisIndex = -1;
- if (thisIndex == -1) {
+ static boost::thread_specific_ptr<int> thisIndex;
+ if (thisIndex.get() == NULL) {
sys::Mutex::ScopedLock mutex(accessLock);
- thisIndex = nextThreadIndex;
+ thisIndex.reset(new int(nextThreadIndex));
if (nextThreadIndex < agent->getMaxThreads() - 1)
nextThreadIndex++;
}
- return thisIndex;
+ return *thisIndex;
}
Please let me know if posting this is inappropriate or not in the correct
format and I'll try and make it right. Hope this is of any help.
Thanks,
Kevin
-----Original Message-----
From: Steve Huston (JIRA) [mailto:[email protected]]
Sent: Thu 5/21/2009 2:36 PM
To: [email protected]
Subject: [jira] Commented: (QPID-1868) Implicit TLS variables in AsyncIO can
cause access violation when dynamically loading qpidcommon and qpidclient DLLs
[
https://issues.apache.org/jira/browse/QPID-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711747#action_12711747
]
Steve Huston commented on QPID-1868:
------------------------------------
As Andrew noted, we can remove the TSS-based variables in AsynchIO altogether,
which would be easier. They're not referenced anywhere outside AsynchIO.cpp, so
it's no point jumping through hoops for something that's not used. Sorry I
didn't notice this earlier.
However, there's another QPID_TSS in qpid/management/ManagementObject.cpp -
since this is included in qpidcommon, it also needs to be fixed. And, no,
requiring Vista/WinServer 2008 is not an option. Much of the Windows user world
is still in XP land.
> 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
>
>
> 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:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
