Thread overview
How to avoid invalid memory operation errors (and more) in DLLs?
Dec 26, 2014
Heinz
Jan 14, 2015
John Colvin
Jan 18, 2015
Heinz
December 26, 2014
Hello everyone,

I'm making a big framework with D2 (DMD 2.066.1) and I've been
encountering many errors related to threads in DLLs.

My program flow is a main exe wich statically loads a main dll,
then this main dll dynamically loads an extra dll and then this
extra dll dynamically loads a final dll. Inside this flow i only
create 2 threads for a total of 3 including the main thread.
Using the included debugger in DMD, it shows that 5 threads are
created but i can't understand why the extra 2 are spanned.

The problem is that in the final dll whenever i make calls to
functions exclusive to this dll i get "invalid memory operation"
errors. I don't know if this is TLS related but i have __gshared
everywhere in my framework and compiling with -vtls shows no tls
globals.

While trying to debug the program i found a bug (i think) present
in all DMD2 latest versions: I named all threads so i could
identify them in the debugging process by assigning the
core.thread.Thread.name property. But in the already mentioned
final dll, whenever i try to get the core.thread.Thread.name
property to print it, the whole program crashes.
Luckily i was able to reproduce this bug by making a very simple
and scaled down demo. It's flow is similar to my real program: A
main exe statically loads a main dll and then the main dll
dynamically loads an auxiliary dll from wich i try to print the
thread's name but the whole demo crashes.

Here's the test case i made, it includes binaries and source
code:
https://dl.dropboxusercontent.com/u/2351331/dll-tls%20test_case.zip

Just run the program and type the word "magic", it will load up
to the auxiliary dll wich will try to print the current thread
name but it will crash.
If anyone with more experience in DLL matters could confirm if
the above behavior is indeed a bug i'll be greatly appreciated.

Finally, if possible, i'd like to receive suggestions on how to
avoid extra threads from being created and avoid memory operation
errors in DLLs.

Thank you guys for your time (and brains) and i hope you had a
great x-mas.
January 14, 2015
On Friday, 26 December 2014 at 00:40:45 UTC, Heinz wrote:
> Hello everyone,
>
> I'm making a big framework with D2 (DMD 2.066.1) and I've been
> encountering many errors related to threads in DLLs.
>
> My program flow is a main exe wich statically loads a main dll,
> then this main dll dynamically loads an extra dll and then this
> extra dll dynamically loads a final dll. Inside this flow i only
> create 2 threads for a total of 3 including the main thread.
> Using the included debugger in DMD, it shows that 5 threads are
> created but i can't understand why the extra 2 are spanned.
>
> The problem is that in the final dll whenever i make calls to
> functions exclusive to this dll i get "invalid memory operation"
> errors. I don't know if this is TLS related but i have __gshared
> everywhere in my framework and compiling with -vtls shows no tls
> globals.
>
> While trying to debug the program i found a bug (i think) present
> in all DMD2 latest versions: I named all threads so i could
> identify them in the debugging process by assigning the
> core.thread.Thread.name property. But in the already mentioned
> final dll, whenever i try to get the core.thread.Thread.name
> property to print it, the whole program crashes.
> Luckily i was able to reproduce this bug by making a very simple
> and scaled down demo. It's flow is similar to my real program: A
> main exe statically loads a main dll and then the main dll
> dynamically loads an auxiliary dll from wich i try to print the
> thread's name but the whole demo crashes.
>
> Here's the test case i made, it includes binaries and source
> code:
> https://dl.dropboxusercontent.com/u/2351331/dll-tls%20test_case.zip
>
> Just run the program and type the word "magic", it will load up
> to the auxiliary dll wich will try to print the current thread
> name but it will crash.
> If anyone with more experience in DLL matters could confirm if
> the above behavior is indeed a bug i'll be greatly appreciated.
>
> Finally, if possible, i'd like to receive suggestions on how to
> avoid extra threads from being created and avoid memory operation
> errors in DLLs.
>
> Thank you guys for your time (and brains) and i hope you had a
> great x-mas.

Would it be possible for you to file this as a bug at issues.dlang.org ?
January 18, 2015
On Wednesday, 14 January 2015 at 13:51:08 UTC, John Colvin wrote:

> Would it be possible for you to file this as a bug at issues.dlang.org ?

While trying to file this issue, I was simplifing my test case and in the process I was able to make it not crash, but now core.thread.Thread.getThis().name() is always empty, even if i __gshared everything so i guess this is one of those non trackable, non fixable issues that default TLS introduced.

This is so confusing and frustrating right now, I can't report this as a bug because I was able to fix the crash, but I wasn't able to obtain the desired results in my program, maybe a programming or implementation error?

I'm taking a break right now with D, I've been stuck for too long with these threading/tls issues. I need vacations.