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?

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.

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

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.

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.

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

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.

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)

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!

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