digitalmars.D.learn - How to avoid invalid memory operation errors (and more) in DLLs?
- Heinz (38/38) Dec 25 2014 Hello everyone,
- John Colvin (3/43) Jan 14 2015 Would it be possible for you to file this as a bug at
- Heinz (12/14) Jan 18 2015 While trying to file this issue, I was simplifing my test case
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
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
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