www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why filling AA in shared library freezes execution?

reply Vitalii <yvitaliy1980 yandex.ru> writes:
I'm sorry to post it for third time, but I haven't received any 
helpful advice.
Is it too simple and nooby? Could you please just give me link to 
the similar code/discussion?

Q: Why filling assoc.array in shared library freeze execution?
Try to run test_dll_exe.exe several times:
----
// test_dll.d
import std.stdio;
import core.sys.windows.windows;
import core.sys.windows.dll;

mixin SimpleDllMain;

extern(C) {

export void TestFun() {
     double[int] T;
     foreach (i; 0..10_000_000) {
         writefln("i:%d",i);
         T[i] = i*1.0;
     }
}

}
----
// test_dll_exe.d
import core.runtime;
import core.sys.windows.windows;
import std.exception;

void main() {
     HMODULE test_dll = cast(HMODULE) 
enforce(Runtime.loadLibrary("test_dll.dll"));

     alias extern(C) void function() Test_type;
     Test_type TestFun = cast(Test_type) 
enforce(GetProcAddress(test_dll, "TestFun"));
     TestFun();
}
----
Problem reproduces with dmd 2.095.0 and ldc2 1.24 on Windows 7 
SP1, Intel i7 4790.
Compile options:
dmd -m64 -shared -oftest_dll.dll -L/DLL test_dll.d
dmd -m64 test_dll_exe.d
or
ldc2.exe --m64 --shared --of=test_dll.dll -L=/DLL test_dll.d
ldc2.exe --m64 test_dll_exe.d

If I replace double[int] T with array double[] T; T ~= i*0.01; 
it's still freezes after some iteration. But if I add in last 
case T.length = 10_000_000; T[i] = i*0.01; it's doing just fine. 
Any ideas? How to allocate memory in shared library properly?
Jan 25
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 I'm sorry to post it for third time, but I haven't received any 
 helpful advice.
Please don't start multiple threads for the same topic. If no one has helped you yet, it means either no one with an answer has seen it or that no one has an answer. You can reply to your original post to bump that thread rather than posting new threads.
Jan 25
parent reply Vitalii <yvitaliy1980 yandex.ru> writes:
On Tuesday, 26 January 2021 at 05:37:02 UTC, Mike Parker wrote:
 On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 I'm sorry to post it for third time, but I haven't received 
 any helpful advice.
Please don't start multiple threads for the same topic. If no one has helped you yet, it means either no one with an answer has seen it or that no one has an answer. You can reply to your original post to bump that thread rather than posting new threads.
OK, thank you Mike I'll never do that again. It's quite unexpected for me that nobody give me some help about usage of AA in shared library. Nobody use shared library? Nobody use AA? Post with trivial questions about OpAssign gets many answers. Even post about changing logo color from red to blue gets almost 50 replies. With all rules of decorum I post reproducible source code and ask any help. Where is language community? Vitalii
Jan 25
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 26 January 2021 at 06:53:22 UTC, Vitalii wrote:

 help about usage of AA in shared library. Nobody use shared 
 library? Nobody use AA?
 Post with trivial questions about OpAssign gets many answers.
 Even post about changing logo color from red to blue gets 
 almost 50 replies.
 With all rules of decorum I post reproducible source code and 
 ask any help.
 Where is language community?
A lot of topics get answers, sure. It's easy to comment on logo colors, or trivial issues. But for your situation... You seem have hit a corner case, and that means that it's going to be something that a lot of people never encountered. So yes, this is a very different situation than opAssign or logo colors. If I could help you, I would, but I have no idea what the problem is and I don't have time to try to reproduce it myself. Please be patient and someone will help you if they can.
Jan 25
prev sibling parent reply frame <frame86 live.com> writes:
On Tuesday, 26 January 2021 at 06:53:22 UTC, Vitalii wrote:

 It's quite unexpected for me that nobody give me some
 help about usage of AA in shared library. Nobody use shared 
 library? Nobody use AA?
 Post with trivial questions about OpAssign gets many answers.
 Even post about changing logo color from red to blue gets 
 almost 50 replies.
 With all rules of decorum I post reproducible source code and 
 ask any help.
 Where is language community?

 Vitalii
You get this wrong. It's nothing bad with your code. It's a problem with your OS or compiler support or even your CPU has some bug. If you have nothing special in dll.d we do not see, it should run without problems. You can try out VisualD for Visual Studio which may can give you a hint of the error you get before your app is freezing.
Jan 26
parent reply Vitalii <yvitaliy1980 yandex.ru> writes:
On Tuesday, 26 January 2021 at 08:14:10 UTC, frame wrote:
 On Tuesday, 26 January 2021 at 06:53:22 UTC, Vitalii wrote:

 It's quite unexpected for me that nobody give me some
 help about usage of AA in shared library. Nobody use shared 
 library? Nobody use AA?
 Post with trivial questions about OpAssign gets many answers.
 Even post about changing logo color from red to blue gets 
 almost 50 replies.
 With all rules of decorum I post reproducible source code and 
 ask any help.
 Where is language community?

 Vitalii
You get this wrong. It's nothing bad with your code. It's a problem with your OS or compiler support or even your CPU has some bug. If you have nothing special in dll.d we do not see, it should run without problems. You can try out VisualD for Visual Studio which may can give you a hint of the error you get before your app is freezing.
Thank you frame! Just simple mention that code doesn't contains obvious mistakes help me a lot. dll.d is code from https://wiki.dlang.org/Win32_DLLs_in_D, I replace it with mixin SimpleDllMain; but result was the same. Also I write the same code in C++, compile it with Intel C++ 2013 compiler and get no errors at all. You give me a hint to try it on another OS - I tried on Windows Server 2012 R2 and Intel Xeon Gold 6134 - and it works! So it's really OS-dependent thing. I'll be waiting for bugfix release. Vitalii
Jan 26
parent frame <frame86 live.com> writes:
On Tuesday, 26 January 2021 at 11:17:11 UTC, Vitalii wrote:
I'll be waiting for bugfix release.

There could also be other reasons if your system is "compromised" 
by a Hijack-DLL thats automatically included when your app starts 
by an Anti-Virus scanner or some bug in a C++ updated or outdated 
runtime part. I would try it on a clean system again.
Jan 26
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 Q: Why filling assoc.array in shared library freeze execution?
D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs. That's the sad reality of it. I'd suggest finding a different approach. Maybe IPC or maybe making either the exe or dll not use druntime (like redesigning for -betterC, though even there it is tricky since like global variables aren't imported from the dll by the compiler, you have to do extra indirection yourself)
Jan 26
next sibling parent reply Vitalii <yvitaliy1980 yandex.ru> writes:
On Tuesday, 26 January 2021 at 14:12:17 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 Q: Why filling assoc.array in shared library freeze execution?
D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs. That's the sad reality of it. I'd suggest finding a different approach. Maybe IPC or maybe making either the exe or dll not use druntime (like redesigning for -betterC, though even there it is tricky since like global variables aren't imported from the dll by the compiler, you have to do extra indirection yourself)
Thank you, Adam!
Jan 26
parent Siemargl <inqnone gmail.com> writes:
Vitalii,

I test your program and it runs without any problem. Consuming 
about 1Gb RAM at end.

But i have а slightly different environment.

Win10 1909 x64, DMD32 D Compiler v2.092.1-dirty
Jan 26
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 26, 2021 at 02:12:17PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:
 On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 Q: Why filling assoc.array in shared library freeze execution?
D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs.
[...] Just out of curiosity, what are some of the showstoppers? I'd have expected D exe's loading D dll's should be the first priority in making Windows dll's work in D. I'm surprised there are still obvious problems. T -- Frank disagreement binds closer than feigned agreement.
Jan 26
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Tuesday, 26 January 2021 at 17:39:50 UTC, H. S. Teoh wrote:
 On Tue, Jan 26, 2021 at 02:12:17PM +0000, Adam D. Ruppe via 
 Digitalmars-d-learn wrote:
 On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
 Q: Why filling assoc.array in shared library freeze 
 execution?
D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs.
[...] Just out of curiosity, what are some of the showstoppers? I'd have expected D exe's loading D dll's should be the first priority in making Windows dll's work in D. I'm surprised there are still obvious problems. T
The biggest one for me, is that RTTI isn't "shared" across boundaries. So typeid(int) in your .exe isn't compatible with typeid(int) from a .dll I found out the hard way, since sdlang-d was giving me a very strange type mismatch error which was caused due to this issue in typeid. Am I wrong in saying that it was fixed at some point though, or at least, someone was attempting a fix? It's kind of discouraging to hear from Adam that there's actually even *more* issues regarding DLLs. I've crossed them out of my mind entirely at this point though, since Windows in general doesn't seem to get much love in certain parts of D (e.g. the makefile for Phobos didn't support things that the posix makefile did).
Jan 27
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 27 January 2021 at 13:39:32 UTC, SealabJaster wrote:
 I've crossed them out of my mind entirely at this point though, 
 since Windows in general doesn't seem to get much love in 
 certain parts of D (e.g. the makefile for Phobos didn't support 
 things that the posix makefile did).
Should just quickly clarify that these "certain parts of D" are usually minor/niche parts and things.
Jan 27
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 27 January 2021 at 13:39:32 UTC, SealabJaster wrote:
 The biggest one for me, is that RTTI isn't "shared" across 
 boundaries.
Yeah, that's a big one. Exception handling tables are also not properly merged leading to random behavior even if you do manage to catch the exception (I wrote a PR for that but it isn't theoretically sound https://github.com/dlang/druntime/pull/2874# ), the GC proxy is done wrong - but there might be a chance to fix that - and there's a bug with static data not being scanned. Possibly related to the GC proxy, not sure. It is all related to the same root problem - on Windows, unlike Linux, symbols are not automatically merged. More info http://dconf.org/2016/talks/thaut.html Yes, from 2016. And a branch aiming to fix it: https://github.com/ingrater/dmd/tree/DllSupportD So what happens is if you have a global variable in the dll and exe, each one has their own copy of it. So typeid are not merged, GC meta is not merged. druntime tries to hack around this but it doesn't do a good job. But then in user libs the same thing happens and they almost never make any attempt to handle it, so if you using other stuff, there be dragons. It might be perfectly fine, separate copies of data is often not fatal at all. But if they expect sharing - you can get separate singletons and such - you're in some trouble. Technically what dmd does for dlls isn't wrong. That is the way the underlying operating system works. But since it is more useful to handle these things and the Microsoft C++ compilers paper over this with auto-generated indirection, even Windows programmers might not realize it and it just seems completely broken. (btw as for me fixing it myself, there's a number of subtleties that I don't even know. Maybe i could figure them out but the fact is it is prolly gonna be a buggy transition. But the most discouraging part is seeing all that talk and code from 2016 just sitting there, ignored. What's the point of even trying if it is just going to rot again.)
Jan 27
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe 
wrote:
 (btw as for me fixing it myself
oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.
Jan 27
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 27, 2021 at 02:39:08PM +0000, Adam D. Ruppe via Digitalmars-d-learn
wrote:
 On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe wrote:
 (btw as for me fixing it myself
oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.
I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before? T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Jan 27
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
 I'm surprised this stuff hasn't been fixed yet, considering 
 Walter (mostly?) works on Windows. Has he never run into these 
 issues before?
It had a dconf talk spell it all out. But it can be difficult to reproduce the nasty cases in a reduced test. Well, the exception catching ones are trivial to reproduce, it just plain doesn't work. But the GC and EH tables not lining up are harder to find. The EH table one rears its head once you fix the typeinfo problem that prevents the catch in the first place. But then the GC one is just hard to trigger. Unless you're using dll plugins in my day job project. (but even there it only happens after like 100 iterations of stuff, just the day job scripts run hundreds of times a day so you see it regularly... just can't fix it...)
Jan 27
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 27 January 2021 at 16:38:07 UTC, Adam D. Ruppe 
wrote:
 ...
Yikes! Ok, I thought DLLs were just "sort of" unusable due to the RTTI issue, but now I'm convinced that they're almost completely useless in their current state unless you want to live in a world of hurt and pain. It's almost comical. At least the underlying issue is complicated, instead of it rather being a case of "no one's worked on it at all". Unfortunately, the underlying issue is complicated, so I don't have the greatest faith in DLLs becoming useable anytime soon. Thanks for the explanation.
Jan 27
parent reply frame <frame86 live.com> writes:
On Thursday, 28 January 2021 at 07:51:06 UTC, SealabJaster wrote:
 On Wednesday, 27 January 2021 at 16:38:07 UTC, Adam D. Ruppe 
 wrote:
 ...
Yikes! Ok, I thought DLLs were just "sort of" unusable due to the RTTI issue, but now I'm convinced that they're almost completely useless in their current state unless you want to live in a world of hurt and pain.
At least at Windows 10, DLLs are "working" except you can't throw exceptions and must use some form of exception proxy and wrapper to not ending in "illegal instructions". I can also compare TypeInfos by using the string representation which works fine.
Jan 28
parent reply Siemargl <inqnone gmail.com> writes:
Update. Something is broken in DLL support in druntime for Win7.

I take previous working in Win10 binary and try run it in virtual 
Windows 7 SP1 x64.
Got this
C:\Proj\dtest>test_dll_exe.exe

object.Exception test_dll_exe.d(7): Enforcement failed
----------------
0x00000001400013A3
0x00000001400012CC
0x0000000140001074
0x0000000140004123
0x0000000140003FAC
0x000000014000408B
0x0000000140003FAC
0x0000000140003EF3
0x00000001400019D0
0x0000000140001114
0x000000014002F60E
0x00000000771359CD in BaseThreadInitThunk
0x000000007736A561 in RtlUserThreadStart

Then i modify program, just removing DLL, copying TestFun() in 
main module and it runs.
Same compiler -m64 target.
Jan 28
next sibling parent reply frame <frame86 live.com> writes:
On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
 Update. Something is broken in DLL support in druntime for Win7.

 I take previous working in Win10 binary and try run it in 
 virtual Windows 7 SP1 x64.
 Got this
You can't expect that a Win10 build also runs on Win7.
Jan 28
parent reply Siemargl <inqnone gmail.com> writes:
On Thursday, 28 January 2021 at 16:46:40 UTC, frame wrote:
 On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
 Update. Something is broken in DLL support in druntime for 
 Win7.

 I take previous working in Win10 binary and try run it in 
 virtual Windows 7 SP1 x64.
 Got this
You can't expect that a Win10 build also runs on Win7.
Why not? Only VS2013 runtime is prereq for DMD programs
Jan 28
parent frame <frame86 live.com> writes:
On Thursday, 28 January 2021 at 17:00:35 UTC, Siemargl wrote:
 On Thursday, 28 January 2021 at 16:46:40 UTC, frame wrote:
 On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
 Update. Something is broken in DLL support in druntime for 
 Win7.

 I take previous working in Win10 binary and try run it in 
 virtual Windows 7 SP1 x64.
 Got this
You can't expect that a Win10 build also runs on Win7.
Why not? Only VS2013 runtime is prereq for DMD programs
* you shouln't assume I just guess that the library loading code is different between 7 and 10. I get the same error if I try to load a LDC compiled DLL in a DMD executable. Did you try to compile the DLL on Win 7 too?
Jan 28
prev sibling parent reply Siemargl <inqnone gmail.com> writes:
On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
 Update. Something is broken in DLL support in druntime for Win7.

 I take previous working in Win10 binary and try run it in 
 virtual Windows 7 SP1 x64.
 Got this
 C:\Proj\dtest>test_dll_exe.exe

 object.Exception test_dll_exe.d(7): Enforcement failed
 ----------------
 0x00000001400013A3
 0x00000001400012CC
 0x0000000140001074
 0x0000000140004123
 0x0000000140003FAC
 0x000000014000408B
 0x0000000140003FAC
 0x0000000140003EF3
 0x00000001400019D0
 0x0000000140001114
 0x000000014002F60E
 0x00000000771359CD in BaseThreadInitThunk
 0x000000007736A561 in RtlUserThreadStart

 Then i modify program, just removing DLL, copying TestFun() in 
 main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
Jan 28
parent reply Siemargl <inqnone gmail.com> writes:
On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

 Then i modify program, just removing DLL, copying TestFun() in 
 main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
Jan 28
next sibling parent reply frame <frame86 live.com> writes:
On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
 On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

 Then i modify program, just removing DLL, copying TestFun() 
 in main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
You should really try to use a debugger to see what error is thrown in first chance. It also helps to identify a possible hidden problem that is not reproducable on other machines.
Jan 29
parent Siemargl <inqnone gmail.com> writes:
On Friday, 29 January 2021 at 10:10:56 UTC, frame wrote:
 On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
 On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

 Then i modify program, just removing DLL, copying TestFun() 
 in main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
You should really try to use a debugger to see what error is thrown in first chance. It also helps to identify a possible hidden problem that is not reproducable on other machines.
Sorry, there are many problems debugging D x64 on Windows. All i can get, is call stack from crash dump ntdll!ZwWaitForSingleObject+0xa ntdll!RtlDeNormalizeProcessParams+0x5a8 ntdll!RtlDeNormalizeProcessParams+0x4a4 ntdll!RtlInitializeCriticalSectionEx+0x3b9 KERNELBASE!HeapDestroy+0x3a KERNELBASE!GetModuleHandleExW+0x39 test_dll!TestFun+0x576b6 test_dll!TestFun+0x55bf3 test_dll!TestFun+0x4e315 test_dll!TestFun+0x4d86f test_dll!TestFun+0x4bdb5 test_dll!TestFun+0x507e1 test_dll!TestFun+0x4756b test_dll!TestFun+0x22d1d test_dll!TestFun+0x23d9a test_dll!TestFun+0x1a1b9 test_dll!TestFun+0x93 test_dll_exe!D main+0xe5 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c
Jan 30
prev sibling parent reply Vitalii <yvitaliy1980 yandex.ru> writes:
On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
 On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

 Then i modify program, just removing DLL, copying TestFun() 
 in main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
. Thank you, Siemargl! It's just the same behaviour that I got. The same number 64511. If you change double[int] to double[], the number would be around ~520.000, if int[] then ~1.000.000. I make conclusion that there is something concerning memory limit of 4 Mb.
Jan 30
parent reply Siemargl <inqnone gmail.com> writes:
On Saturday, 30 January 2021 at 19:52:09 UTC, Vitalii wrote:
 On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
 On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

 Then i modify program, just removing DLL, copying TestFun() 
 in main module and it runs.
 Same compiler -m64 target.
Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
. Thank you, Siemargl! It's just the same behaviour that I got. The same number 64511. If you change double[int] to double[], the number would be around ~520.000, if int[] then ~1.000.000. I make conclusion that there is something concerning memory limit of 4 Mb.
No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it.
Jan 30
parent reply Siemargl <inqnone gmail.com> writes:
On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote:
 No, this is a deadlock in memory manager.

 To find roots of problem, needed a debug version of druntime, 
 but i were unsuccesfull to compile it.
I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals ntdll!ZwWaitForSingleObject+0xa ntdll!RtlDeNormalizeProcessParams+0x5a8 ntdll!RtlDeNormalizeProcessParams+0x4a4 ntdll!RtlInitializeCriticalSectionEx+0x3b9 KERNELBASE!HeapDestroy+0x3a KERNELBASE!GetModuleHandleExW+0x39 test_dll!D4core6thread8osthread23ll_startDLLUnloadThreadFNbNiZb+0x86 test_dll!D4core6thread8osthread20createLowLevelThreadFNbNiDFNbZvkDFNbZvZk+0x153 test_dll!D2gc4impl12conservativeQw3Gcx16startScanThreadsMFNbZv+0xc5 test_dll!D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm+0x12f test_dll!D2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv+0x135 test_dll!D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl+0xa1 test_dll!D2gc4impl12conservativeQw14ConservativeGC6mallocMFNbmkxC8TypeInfoZPv+0x4b test_dll!gc_malloc+0x2d test_dll!aaGetX+0x2ca test_dll!aaGetY+0x39 test_dll!test_dll.TestFun+0x93 test_dll_exe!D main+0x111 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c
Feb 06
parent reply Siemargl <inqnone gmail.com> writes:
On Saturday, 6 February 2021 at 10:44:08 UTC, Siemargl wrote:
 On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote:
 No, this is a deadlock in memory manager.

 To find roots of problem, needed a debug version of druntime, 
 but i were unsuccesfull to compile it.
I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals
.... So it seems, that disabling parallel GC, solves problem. I add in BOTH dll and main module and cant reproduce freeze anymore extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ];
Feb 06
parent Siemargl <inqnone gmail.com> writes:
On Saturday, 6 February 2021 at 15:21:17 UTC, Siemargl wrote:
 extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" 
 ];
LDC 1.24 is also affected and rt_options helps
Feb 13
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
 On Wed, Jan 27, 2021 at 02:39:08PM +0000, Adam D. Ruppe via 
 Digitalmars-d-learn wrote:
 On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe 
 wrote:
 (btw as for me fixing it myself
oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.
I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before? T
Anyone knows what it would take to fix it?
Jan 29
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 29, 2021 at 12:45:02PM +0000, Imperatorn via Digitalmars-d-learn
wrote:
 On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
 On Wed, Jan 27, 2021 at 02:39:08PM +0000, Adam D. Ruppe via
 Digitalmars-d-learn wrote:
 On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe wrote:
 (btw as for me fixing it myself
oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.
I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before?
[...]
 Anyone knows what it would take to fix it?
Somebody who (1) knows enough of compiler internals to be able to fix this, (2) is intimately familiar with how Windows dlls work, (3) is desperate enough to do the work himself instead of waiting for someone else to do it, and (4) is stubborn enough to push it through in spite of any resistance. T -- Never wrestle a pig. You both get covered in mud, and the pig likes it.
Jan 29
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 29 January 2021 at 15:34:49 UTC, H. S. Teoh wrote:
 On Fri, Jan 29, 2021 at 12:45:02PM +0000, Imperatorn via 
 Digitalmars-d-learn wrote:
 On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh 
 wrote:
 On Wed, Jan 27, 2021 at 02:39:08PM +0000, Adam D. Ruppe via 
 Digitalmars-d-learn wrote:
 [...]
I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before?
[...]
 Anyone knows what it would take to fix it?
Somebody who (1) knows enough of compiler internals to be able to fix this, (2) is intimately familiar with how Windows dlls work, (3) is desperate enough to do the work himself instead of waiting for someone else to do it, and (4) is stubborn enough to push it through in spite of any resistance. T
Who would that special someone be? 🤔
Jan 30
prev sibling parent apz28 <home home.com> writes:
On Friday, 29 January 2021 at 12:45:02 UTC, Imperatorn wrote:
 Anyone knows what it would take to fix it?
This may help to narrow down the problem. Disable garbage collect Configuring the Garbage Collector https://dlang.org/spec/garbage.html https://stackoverflow.com/questions/472133/turning-off-the-d-garbage-collector Or change it so that there is only one thread Parallel marking https://dlang.org/spec/garbage.html
Jan 29