<div dir="ltr">Can the memory mapping outlive the file handle? I bet it can.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 3:17 PM, Ivan Koster <span dir="ltr"><<a href="mailto:ivankoster@gmail.com" target="_blank">ivankoster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Ivan,<br></blockquote><div><br></div><div>Hello! </div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is good info; MemoryBuffer::getOpenFile conditionally uses file<br>
mappings or normal file reads depending on file size (see<br>
MemoryBuffer.cpp/shouldUseMmap).<br>
<br>
Since the mapping uses a stricter sharing mode than the normal file<br>
read, it's more likely to fail. Still not sure who's writing/deleting<br>
the file while Clang attempts to map it, can you make that out from<br>
your PM logs?<br></blockquote><div><br></div></span><div>I've exported the log to csv and you can find it here: <a href="https://drive.google.com/file/d/0B8xFlIzMhHcpdzR6OW4wM3BZdGM/view?usp=sharing" target="_blank">https://drive.google.com/file/d/0B8xFlIzMhHcpdzR6OW4wM3BZdGM/view?usp=sharing</a></div><div><br></div><div>This is a log of sublime text opening dummy.c, commanding YCMD (python.exe) to analyze the dummy.c, which so and so on then finally makes libclang.dll open dummy.h, and finally me killing the python.exe process.</div><div>As you can see, killing the proces does not log anything, even though it "frees" the file.</div><div><br></div><div>The trace shows two threads of libclang.dll (TID 6888 and TID 4040), but they do not operate concurrently. 4040 only starts after 6888 is done with dummy.h.</div><div>When I examine the stack traces of the CreateFileMapping operation that appears in pairs, they both happen in the same kernel32.dll CreateFileMappingA function.</div><div>So the kernel seems to work around the FILE LOCKED WITH ONLY HEADERS thing here?</div><div><br></div><div>There are no dangling file handles, the trace shows only pairs of open and close events. This is confirmed by the windows handle.exe tool, which can not find any filehandles to dummy.h even though the file is locked.</div><div>The weird thing is that the windows Process Explorer has a "find file handle or DLL" function.</div><div>When I make it search for dummy.h, it finds not a file handle, but a DLL inside python.exe called dummy.h. </div><div>Somehow Process Explorer reports that dummy.h is loaded as a DLL? (When I kill python.exe this disappears).</div><div><br></div><div>I haven't dived so deep into windows stuff before so I'm hoping this helps!<br></div><div>But to be honest, this is starting to not make sense to me. The file is locked even though there is no open file handle. Process Explorer reporting that it is loaded as a DLL...</div><div><br></div><div>Regards,</div><div><br></div><div>Ivan</div></div></div></div>
</blockquote></div><br></div>