 |
lua-l archive |
|
|
||
|
On 29/04/2012 08:04, Peng Zhicheng wrote:
I don't have your problem on my Windows XP x64 box. so I can't clearly figure out what was going wrong. My debugger only caught one VERIFIER STOP 0013, and that was in some system DLL range, not lua or mylib.
I just tried the same experiment on Windows 7 x64 with MinGW64 (GCC 4.6.3) and got the same error. Could you give the details about how you build the test application, GCC version, etc.?
But I think your problem is not in lua or mylib either, maybe the C-runtime. but even if the TLS problem do exists, I suppose it won't affect a program which is not multithreaded.
As stated above, the behavior is identical on 32 bit Windows XP and 64 bit Windows 7. May be it is msvcrt.dll that causes the problem in both cases.
My understanding is that the "default" build that does not use any "special" CFLAGS or LDFLAGS should run without any errors.
TLS is for multithreaded programs to use per-thread variables. the native TLS API is kind of low level API on Windows. Normally the compiler and C-runtime would abstract these away, so you can deal with per-thread variable at high level. for instance, GCC uses the __thread keyword(C99, IIRC), and MSVC uses __declspec(thread), to declare thread local variable for those applications not using thread local storage, or even not multithreaded, you don't need to have concerns about TLS. the message your Application Verifier gave seem to state that the DLL had allocated some TLS slots but not freeing them on unloading. if your program did not use the __thread variable or not multithreaded, probably it is due to some __thread variable used by the C-runtime. I suppose this is not big problem.
However I'd like to understand what part of the program causes this (may be insignificant) problem and how to avoid it.
-- Shmuel