www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to avoid invalid memory operation errors (and more) in DLLs?

reply "Heinz" <malagana15 yahoo.es> writes:
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.
Dec 25 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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 ?
Jan 14 2015
parent "Heinz" <malagana15 yahoo.es> writes:
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.
Jan 18 2015