Re: LDC2 and classic profiling
On Friday, 10 May 2019 at 18:09:28 UTC, Johan Engelen wrote: You only need `-fprofile-instr-generate` for generating default.profraw. Yep, it is because I also tried to use uftrace and xray contains only calls to external libraries That's impossible, because those are exactly _not_ profiled. Yes. Probably, it was uftrace output. But, nevertheless, I do not see calls of my own functions. In addition to the call _Dmain and _D4mainQfFAAyaZ9__lambda2MFZv All another calls is made inside of this lambda - maybe lambdas is not traced by profiler? This may help: https://forum.dlang.org/post/voknxddblrbuywcyf...@forum.dlang.org Already read it.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 19:10:05 UTC, Machine Code wrote: Well, I've had similar issue. The error message says "access denied" which I believe refers to the tmp directory; i.e, the user that is running your executable has no permissions to delete that file. Well, this has nothing to do with access rights, the user have full access to his own temp folder even in the most restrictive windows configuration. According to winapi docs, FreeLibrary doesn't guarantee file close op, and that's why you cannot delete it. Internally, windows maps a memory handle directly into the dll file and that pointer remains active until the application exits. Actually, I ran your example with several sequential calls to FreeLibrary, all returning success, even if it's clear that the internal reference count touched zero after the first call. The lock of the file disappears effectively after the application has exited and the dll can be safely deleted afterwards. If you want this dll deploying mechanism (which I consider a bad approach, contributing to the well known dll hell) check at startup if the dll already exists, delete it and redeploy if the existing one doesn't satisfy your version requirements. To avoid dll hell, dlls must be deployed in the system dir, or at least in the application folder through a normal installation process. In our network environment governed by a restrictive GPO, your application will never run.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote: Hi, this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file. So far I have the following file: import std; void main(string[] args) { import core.runtime; static immutable libcurl = import("libcurl.dll"); import std.file: write; auto libpath = tempDir.buildPath("libcurl.dll"); libpath.write(libcurl); auto libcurlMem = rt_loadLibrary(libpath.toStringz); import std.net.curl; "https://dlang.org/".byLine.count.writeln; rt_unloadLibrary(libcurlMem); remove(libpath); } Compiled with: dmd.exe -Jlibdir test.d It almost work, I can write, load and use the library, but when it comes to removing it nothing works. std.file.FileException@std\file.d(1045): C:\users\cym13\Temp\libcurl.dll: Access denied. 0x00402377 in EntryPoint 0x00413BC7 in EntryPoint 0x00413B49 in EntryPoint 0x004139E3 in EntryPoint 0x0040B77F in EntryPoint 0x7B4754C2 in call_process_entry 0x7B477FC6 in ExitProcess 0x7B4754CE in call_process_entry I tried using an explicit File handle to explicitely close the file after writing to it but that doesn't change anything. I'm pretty sure I'm missing something basic about the way windows handles open files but I don't know what, could someone explain why this doesn't work the way I expect it to? Well, I've had similar issue. The error message says "access denied" which I believe refers to the tmp directory; i.e, the user that is running your executable has no permissions to delete that file. To be honest, I find all the permissions issues on Windows a pain the pass so I did a simple tmp files manager. My application create a tmp folder in same folder as in the executable's directory then delete it when the application finishs. I also did write my own function to geneate a random string meant to be used as tmp filename. To delete the file, it might be finishing something and the OS may hold it for some while; so try to delete the file a couple of times, with some interval between the attemps, I do something like this: void deleteFile(string filename) { import std.file : remove, FileException; enum int nAttempts = 5; enum int interval = 200; // value in ms int n = nAttempts; do { try { remove(filename); } catch(FileException) { // the file may be temporary busy or something, so we try again after a while, few times. sleep(interval); } } while(n --> 0); }
Re: LDC2 and classic profiling
On Friday, 10 May 2019 at 14:00:30 UTC, Denis Feklushkin wrote: Build with dub some package. Profiling are enabled by dub.json: "dflags-ldc": ["-fprofile-instr-generate", "-finstrument-functions", "-cov"], Resulting default.profraw (and generated default.profdata) contains only calls to external libraries, but not my internal functions calls. Why? You only need `-fprofile-instr-generate` for generating default.profraw. contains only calls to external libraries That's impossible, because those are exactly _not_ profiled. This may help: https://forum.dlang.org/post/voknxddblrbuywcyf...@forum.dlang.org -Johan
Re: In what situation can new Struct() return null?
On Fri, May 10, 2019 at 05:32:25PM +, faissaloo via Digitalmars-d-learn wrote: > On Friday, 10 May 2019 at 12:19:29 UTC, Cym13 wrote: > > On Friday, 10 May 2019 at 10:11:51 UTC, faissaloo wrote: > > > My program contains the following statement: > > > auto newChildNode = new Node(); > > > > > > In debugging I have found that this pointer evaluates to null, > > > what could cause this? I should have plenty of memory, my only > > > other idea is some sort of heap corruption. > > > > Could you share a complete, concise, compilable example > > demonstrating that bug? One line is rather short to understand > > what's happening. > > Unfortunately not, I can't seem to reproduce it outside my codebase. Perhaps try Dustmite on it? AFAIK, calling new on a struct should never return null. So there must be something else not quite right here. But without actual code it's anybody's guess as to what it might be. The last time I heard somebody run into this, it was caused by some unrelated compiler codegen bug that left the CPU registers in an inconsistent state, thus causing an unrelated call to `new` to return the wrong value. Perhaps you could try a different compiler to see if that makes a difference? T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: In what situation can new Struct() return null?
On Friday, 10 May 2019 at 12:19:29 UTC, Cym13 wrote: On Friday, 10 May 2019 at 10:11:51 UTC, faissaloo wrote: My program contains the following statement: auto newChildNode = new Node(); In debugging I have found that this pointer evaluates to null, what could cause this? I should have plenty of memory, my only other idea is some sort of heap corruption. Could you share a complete, concise, compilable example demonstrating that bug? One line is rather short to understand what's happening. Unfortunately not, I can't seem to reproduce it outside my codebase.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 15:06:46 UTC, Temtaime wrote: Lol, you don't have to load and unload the curl dll. std.net.curl have its own lazy libcurl loader. But i'm not sure if it tries to find the dll in the temp directory. If it is the case, then it simply doesn't unload the dll when you have called some function from it. As I said it's more about the general idea of bundling DLLs in than libcurl itself, but even in that case it doesn't search the temp directory for it. Besides, if it did, it would be a pretty important vulnerability.
Re: [windows] Can't delete a closed file?
Lol, you don't have to load and unload the curl dll. std.net.curl have its own lazy libcurl loader. But i'm not sure if it tries to find the dll in the temp directory. If it is the case, then it simply doesn't unload the dll when you have called some function from it.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 10:09:23 UTC, Cym13 wrote: Hi, this is likely not related to D itself but hopefully someone can help me with this since I'm rather new to windows programming, I mainly work on linux. I'm trying to bundle a DLL in a binary, write it in a temp folder, use it and remove the dangling file. [...] That's a windows "feature". You can't delete files that are in use. The fact that you close the file in your program isn't a guarantee that there's no other open handles around. For the same reason you have to restart windows after every update to apply it.
LDC2 and classic profiling
Build with dub some package. Profiling are enabled by dub.json: "dflags-ldc": ["-fprofile-instr-generate", "-finstrument-functions", "-cov"], Resulting default.profraw (and generated default.profdata) contains only calls to external libraries, but not my internal functions calls. Why?
Re: In what situation can new Struct() return null?
On Friday, 10 May 2019 at 10:11:51 UTC, faissaloo wrote: My program contains the following statement: auto newChildNode = new Node(); In debugging I have found that this pointer evaluates to null, what could cause this? I should have plenty of memory, my only other idea is some sort of heap corruption. Could you share a complete, concise, compilable example demonstrating that bug? One line is rather short to understand what's happening.
In what situation can new Struct() return null?
My program contains the following statement: auto newChildNode = new Node(); In debugging I have found that this pointer evaluates to null, what could cause this? I should have plenty of memory, my only other idea is some sort of heap corruption.
Blog Post #0034 - A Singleton AccelGroup
In today's blog post is an example of how to use a singleton for the AccelGroup, so you don't have to pass a reference down through a gazillion levels to get it to the MenuItems. It's right here: http://gtkdcoding.com/2019/05/10/0034-accelgroup_singleton.html
Re: Erasing passwords from ram?
On Thursday, 9 May 2019 at 19:10:04 UTC, Nick Sabalausky wrote: On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote: I am currently programming a server. So I got the idea that after I've generated all the hashes I need from a password, I want to erase it from RAM before discarding it, just to be sure it won't float around if the server memory is exposed to spyware by some buffer overflow. Is this wise caution, or just being too paranoid? I've seen this done, and regardless of likelihoods, it doesn't hurt as a precaution. The memutils lib offers a tool for this, 'SecureMem': http://code.dlang.org/packages/memutils Good link! The passwords in this case probably aren't worth it (see Cym's replies why), but I'll remember that library if I have to deal with something more sensitive, or just decide to put some extra effort to the security considerations.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 08:07:32 UTC, Cym13 wrote: Which C runtime are you using? The old and buggy DigitalMars one or the official MS one? I really don't know, how can I find out? I litterally just used dmd on the script above with no special options then ran the resulting exe. Yeah, so you're using the old and buggy DigitalMars C runtime. So you can use: - use LDC - use -m64 - use -ms32mscoff and there's a high chance that your problem will go away ;-) They all use the universal C runtime.
Re: [windows] Can't delete a closed file?
On Friday, 10 May 2019 at 07:09:45 UTC, Seb wrote: On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: [...] You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue. Which C runtime are you using? The old and buggy DigitalMars one or the official MS one? I really don't know, how can I find out? I litterally just used dmd on the script above with no special options then ran the resulting exe.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 15:05:10 UTC, Andre Pany wrote: Can you reproduce the issue with other Dlls or is it only reproducible with curl dll? Does the issue with curl dll also exists if you do not call the curl function? Kind regards Andre I didn't have the time to test with another dll just yet but in that specific case the issue disappears if I don't call its functions. That's interesting.
Re: [windows] Can't delete a closed file?
On Thursday, 9 May 2019 at 13:18:44 UTC, Cym13 wrote: On Thursday, 9 May 2019 at 13:02:51 UTC, Rene Zwanenburg wrote: On Thursday, 9 May 2019 at 12:33:37 UTC, Cym13 wrote: [...] You could try to use the find handle function in Process Explorer to figure out what process has the file open: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer I did just that and my test program truly is the only process on the system having that file open. Unless I'm missing something that process-explorer doesn't see and is even true in wine's ultra light environment comprised of a single process, this is definitely not the issue. Which C runtime are you using? The old and buggy DigitalMars one or the official MS one?