Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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" ];
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
On Friday, 29 January 2021 at 15:34:49 UTC, H. S. Teoh wrote: On Fri, Jan 29, 2021 at 12:45:02PM +, 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 +, 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? 樂
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
On Fri, Jan 29, 2021 at 12:45:02PM +, 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 +, 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.
Re: Why filling AA in shared library freezes execution?
On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote: On Wed, Jan 27, 2021 at 02:39:08PM +, 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?
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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 0x0001400013A3 0x0001400012CC 0x000140001074 0x000140004123 0x000140003FAC 0x00014000408B 0x000140003FAC 0x000140003EF3 0x0001400019D0 0x000140001114 0x00014002F60E 0x771359CD in BaseThreadInitThunk 0x7736A561 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
Re: Why filling AA in shared library freezes execution?
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?
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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 0x0001400013A3 0x0001400012CC 0x000140001074 0x000140004123 0x000140003FAC 0x00014000408B 0x000140003FAC 0x000140003EF3 0x0001400019D0 0x000140001114 0x00014002F60E 0x771359CD in BaseThreadInitThunk 0x7736A561 in RtlUserThreadStart Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target.
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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...)
Re: Why filling AA in shared library freezes execution?
On Wed, Jan 27, 2021 at 02:39:08PM +, 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"
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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.)
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
On Tuesday, 26 January 2021 at 17:39:50 UTC, H. S. Teoh wrote: On Tue, Jan 26, 2021 at 02:12:17PM +, 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).
Re: Why filling AA in shared library freezes execution?
On Tue, Jan 26, 2021 at 02:12:17PM +, 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.
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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!
Re: Why filling AA in shared library freezes execution?
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)
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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.
Re: Why filling AA in shared library freezes execution?
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
Re: Why filling AA in shared library freezes execution?
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.
