Dynamic loading of libz3.dll

Question

Dynamic load of a dll statically linked to libz3.dll fails, GetlastError after failed LoadLibrary returns "Invalid access to memory location" error. Is it possible to dynamically load libz3.dll?

Answer 1

Debugging shows that libz3.dll initialization fails in void * memory::allocate(size_t s) on this line: g_memory_thread_alloc_size += s;

The same line in asm:

mov eax,dword ptr [__tls_index (0A79058h)]

mov ecx,dword ptr fs:[2Ch]

mov eax,dword ptr [ecx+eax*4]

The value of g_memory_thread_alloc_size is loaded into the eax register from a location named __tls_index. There is only one thread in the program, the value at __tls_index is zero. Fs points to TEB, fs:[2Ch] points to TEB.ThreadLocalStorage. The next read gets ecx = 0. So the problem is in the uninitialized pointer to TLS.

I'm running my exe on a Windows 2003 Server. Unofficial TLS implementation description say that prior to Windows Vista implicit TLS (using declspec(thread)) does not operate when a module using it is not being loaded at process initialization time (during static import resolution).

This means that the distributed libz3.dll can't be loaded dynamically on Windows earlier than Vista.

Recompiling the dll with not using per thread storage (I changed #if defined(_WINDOWS) || defined(_USE_THREAD_LOCAL) to #if 0) solves the problem. How I understand, not using per thread storage is normal behavior for OSes others, than Windows. Is it OK to use this solution on Windows?

Answer 2

I'm not sure what "statically linked to libz3.dll" means here, but in general, yes, it is possible to load libz3.dll dynamically (our APIs do that as well). One frequently encountered problem is that the system does not provide good error message for when a 32/64 bit conflict occurs, e.g., Python 32-bit will refuse to load a 64-bit DLL and the other way around, both providing error messages that essentially say "there is no libz3.dll".

In this particular case, the complaint about invalid access to memory may indicate that there is a problem in the "statically linked" part.