Re: Application Verifier indicates an error

[Peng Zhicheng <pengzhicheng1986@...>]

于 2012-4-28 3:05, Dimiter 'malkia' Stanev 写道:
> I'm using Windows WDK myself, but have cygwin installed, and from it's mingw, there is i686-w64-mingw32-gcc-4.5.3
>
> and with
> "i686-w64-mingw32-gcc-4.5.3.exe" --help -v -v -v 1>help.txt 2>&1
>
> and then looking in help.txt for TLS reveals this:
>
> -mtls-dialect=
> Use given thread-local storage dialect
>
> -mtls-direct-seg-refs
> Use direct references against %gs when accessing tls data
>
> -ftls-model=[global-dynamic|local-dynamic|initial-exec|local-exec]
> Set the default thread-local storage code generation model
>
> But I'm not sure what these would do
>
> Somehow related - I had a problem with PIXMAN (libpixman) using WDK and TLS, they were working on Vista/Windows 7, but not on XP. I target MSVCRT.DLL and some stuff was missing from there, for that I had to recompile without TLS (for now I won't miss much of it).
>
> On 4/27/2012 5:44 AM, Shmuel Zeigerman wrote:
> > [Windows XP SP3 32 bit, Lua 5.1 and 5.2]
> >
> > Running various Lua binding DLLs with Microsoft Application Verifier, I
> > noticed that all bindings that are C++ give an error. The error message
> > is: "Unloading DLL that allocated TLS index that was not freed."
> >
> > Both Lua and the libraries were built with MinGW 4.5.2.
> > Here is a simple example that reproduces the error.
> >
> > /* mylib.cpp */
> > extern "C" {
> > #include <lua.h>
> > }
> >
> > extern "C" __declspec(dllexport)
> > int luaopen_mylib (lua_State *L)
> > {
> > char* buf = new char;
> > delete buf;
> > return 0;
> > }
> >
> > -- test.lua
> > require "mylib"
> > print "OK" --> it prints OK
> >
> > Here is the log of Application Verifier:
> >
> > <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> > <avrf:logfile xmlns:avrf="Application Verifier">
> > <avrf:logSession TimeStarted="2012-04-27 : 15:10:26" PID="3012"
> > Version="2">
> > <avrf:logEntry Time="2012-04-27 : 15:10:26" LayerName="TLS"
> > StopCode="0x350" Severity="Error">
> > <avrf:message>Unloading DLL that allocated TLS index that was not
> > freed.</avrf:message>
> > <avrf:parameter1>4abba - TLS index</avrf:parameter1>
> > <avrf:parameter2>6e58a0cd - Address of the code that allocated this TLS
> > index.</avrf:parameter2>
> > <avrf:parameter3>153cfe6 - DLL name address. Use du to dump
> > it.</avrf:parameter3>
> > <avrf:parameter4>6e580000 - DLL base address.</avrf:parameter4>
> > <avrf:stackTrace>
> > <avrf:trace>vfbasics!AVrfpCheckAndFreeDllLeakedTlsSlots+62
> > (d:\avrf\source\base\avrf\vrfcommon\dlls.c @ 1204)</avrf:trace>
> > <avrf:trace>vfbasics!AVrfpDllUnloadCallback+51
> > (d:\avrf\source\base\avrf\vrfcommon\dlls.c @ 554)</avrf:trace>
> > <avrf:trace>ntdll!RtlQueryProcessDebugInformation+117e ( @ 0)</avrf:trace>
> > <avrf:trace>ntdll!RtlDeleteAce+4c05 ( @ 0)</avrf:trace>
> > <avrf:trace>vfbasics!AVrfpLdrUnloadDll+5d
> > (d:\avrf\source\base\avrf\vrfcommon\dlls.c @ 1393)</avrf:trace>
> > <avrf:trace>kernel32!FreeLibrary+19 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!luaopen_table+f46 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_getinfo+11f6 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_getinfo+1477 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+13d7 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_getinfo+9e2 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+c5 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+131b ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+139d ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+2230 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!lua_yieldk+7054 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!+402349 ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!+4010db ( @ 0)</avrf:trace>
> > <avrf:trace>lua52!+401178 ( @ 0)</avrf:trace>
> > <avrf:trace>kernel32!RegisterWaitForInputIdle+49 ( @ 0)</avrf:trace>
> > </avrf:stackTrace>
> > </avrf:logEntry>
> > </avrf:logSession>
> > </avrf:logfile>
> >
> > Any comments please?

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.


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.

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.