Messages

1

General Discussion about just::thread / Re: Access Violation using 1.7.3 or 1.7.4 in dynamically loded Windows DLL

« on: August 20, 2012, 07:07:13 PM »

Nice!

I hadn't seen anything about a 1.7.4.1 update.  I just updated and ran the test...fixed!
Thank you sir.

2

General Discussion about just::thread / Access Violation using 1.7.3 or 1.7.4 in dynamically loded Windows DLL

« on: August 19, 2012, 04:16:24 PM »

I’m seeing an Access Violation on unload in crtdll.c on line 531 using 1.7.3 or 1.7.4 (v90 or v100 toolsets) in a dynamically loaded/unloaded Windows DLL.

First-chance exception at 0x000007fefb8bc413 (jtindll.dll) in JTTest.exe: 0xC0000005: Access violation writing location 0x0000000000000410.

From crtdll.c line 531 debugging:
_pRawDllMain = 0x000007fefb8be8d0 `anonymous namespace'::run_tls_callback(void * ptr64,unsigned long,void * ptr64)


The exception appears to be handled, but I am concerned and generally don’t care for anomalous behaviors.  I can provide the test if you wish, but it is pretty simple.  The dll exports start() and stop().  start() creates a thread and stop() joins it.  The exe just loads the dll, calls start then stop and unloads the dll.  This is just native code, no managed nonsense.
Can you confirm/explain this? 

3

General Discussion about just::thread / mutex - owning thread?

« on: May 08, 2012, 12:44:45 PM »

Is there a way to find the owning thread of a std::mutex?  It would be desirable to see this both live and especially in crash dumps.

4

General Discussion about just::thread / #define _AMD64_

« on: October 10, 2011, 12:24:28 PM »

I am getting the following (VS2010, v90 toolset):

1>F:\ThirdParty\just_thread\1.7\include\jss/atomic_impl.hpp(16): error C2220: warning treated as error - no 'object' file generated
1>F:\ThirdParty\just_thread\1.7\include\jss/atomic_impl.hpp(16): warning C4005: '_AMD64_' : macro redefinition
1>          command-line arguments :  see previous definition of '_AMD64_'

I get around it via #undef _AMD64_ before including <atomic>, but I would prefer not to do that.  Maybe you should consider #ifndef _AMD64_ before defining it?  The value is somewhat erratic.  I have found it defined empty and 1.