• Vitalii (47/47) Jan 25 2021 I'm sorry to post it for third time, but I haven't received any
• Mike Parker (5/7) Jan 25 2021 Please don't start multiple threads for the same topic. If no one
• Vitalii (12/21) Jan 25 2021 OK, thank you Mike I'll never do that again.
• Mike Parker (9/17) Jan 25 2021 A lot of topics get answers, sure. It's easy to comment on logo
• frame (7/17) Jan 26 2021 You get this wrong. It's nothing bad with your code. It's a
• Vitalii (13/31) Jan 26 2021 Thank you frame!
• frame (6/6) Jan 26 2021 On Tuesday, 26 January 2021 at 11:17:11 UTC, Vitalii wrote:
• Adam D. Ruppe (8/9) Jan 26 2021 D exes loading D dlls are very broken on Windows. You can kinda
• Vitalii (2/13) Jan 26 2021 Thank you, Adam!
• Siemargl (5/5) Jan 26 2021 Vitalii,
• H. S. Teoh (9/14) Jan 26 2021 [...]
• SealabJaster (16/31) Jan 27 2021 The biggest one for me, is that RTTI isn't "shared" across
• SealabJaster (3/7) Jan 27 2021 Should just quickly clarify that these "certain parts of D" are
• Adam D. Ruppe (34/36) Jan 27 2021 Yeah, that's a big one. Exception handling tables are also not
• Adam D. Ruppe (8/9) Jan 27 2021 oh edit, I should point out it also requires some degree of
• H. S. Teoh (6/14) Jan 27 2021 I'm surprised this stuff hasn't been fixed yet, considering Walter
• Adam D. Ruppe (13/16) Jan 27 2021 It had a dconf talk spell it all out.
• SealabJaster (12/13) Jan 27 2021 Yikes! Ok, I thought DLLs were just "sort of" unusable due to the
• frame (5/12) Jan 28 2021 At least at Windows 10, DLLs are "working" except you can't throw
• Siemargl (23/23) Jan 28 2021 Update. Something is broken in DLL support in druntime for Win7.
• frame (2/6) Jan 28 2021 You can't expect that a Win10 build also runs on Win7.
• Siemargl (3/11) Jan 28 2021 Why not?
• frame (6/18) Jan 28 2021 * you shouln't assume
• Siemargl (3/26) Jan 28 2021 Ups. Sorry, I just forget copy test_dll.dll inside VM :-)
• Siemargl (3/8) Jan 28 2021 I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears.
• frame (4/15) Jan 29 2021 You should really try to use a debugger to see what error is
• Siemargl (23/41) Jan 30 2021 Sorry, there are many problems debugging D x64 on Windows.
• Vitalii (7/18) Jan 30 2021 .
• Siemargl (4/25) Jan 30 2021 No, this is a deadlock in memory manager.
• Siemargl (23/26) Feb 06 2021 I make debug vesion of druntime and catch nicer stacktrace. Maybe
• Siemargl (6/13) Feb 06 2021 ....
• Siemargl (2/4) Feb 13 2021 LDC 1.24 is also affected and rt_options helps
• Imperatorn (2/18) Jan 29 2021 Anyone knows what it would take to fix it?
• H. S. Teoh (10/27) Jan 29 2021 Somebody who (1) knows enough of compiler internals to be able to fix
• Imperatorn (2/25) Jan 30 2021 Who would that special someone be? 🤔
• apz28 (9/10) Jan 29 2021 This may help to narrow down the problem.

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?

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.

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

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.

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.

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

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.

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)

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!

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

"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.

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).

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.

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.)

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.

"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"

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...)

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.

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.

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.

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.

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

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?

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

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

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.

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

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.

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.

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

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" ];

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

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?

"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.

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? 🤔

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