<div dir="rtl"><div dir="ltr">Before this bug report gets lost, Kim is correct about the error code EC, it's an output argument for MemoryBufferMMapFile::MemoryBufferMMapFile and must be passed by reference, like:</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">Index: lib/Support/MemoryBuffer.cpp</div><div dir="ltr">===================================================================</div><div dir="ltr">--- lib/Support/MemoryBuffer.cpp (revision 223970)</div><div dir="ltr">+++ lib/Support/MemoryBuffer.cpp (working copy)</div><div dir="ltr">@@ -203,7 +203,7 @@</div><div dir="ltr"><br></div><div dir="ltr"> public:</div><div dir="ltr"> MemoryBufferMMapFile(bool RequiresNullTerminator, int FD, uint64_t Len,</div><div dir="ltr">- uint64_t Offset, std::error_code EC)</div><div dir="ltr">+ uint64_t Offset, std::error_code &EC)</div><div dir="ltr"> : MFR(FD, false, sys::fs::mapped_file_region::readonly,</div><div dir="ltr"> getLegalMapSize(Len, Offset), getLegalMapOffset(Offset), EC) {</div><div dir="ltr"> if (!EC) {</div></div><div class="gmail_extra"><div dir="ltr"><br></div><div dir="ltr">This passes regression tests.</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br><div class="gmail_quote">2014-12-11 0:15 GMT+02:00 Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex"><div dir="rtl"><div dir="ltr"><span style="font-size:12.7272720336914px">mapped_</span><span style="font-size:12.7272720336914px">file_region </span>is owned by a MemoryBufferMMapFile (MemoryBuffer.cpp) which inherits from MemoryBuffer.</div><div dir="ltr"><br></div><div dir="ltr">The MemoryBuffer for a source file lives in a ContentCache, owned by clang::SourceManager::Fileinfos (SourceManager.cpp).<br></div><div dir="ltr"><br></div><div dir="ltr">The fileinfos structure is destructed in clang SourceManager destructor which happens when clang completes compiling the compilation unit.</div><div dir="ltr"><br></div><div dir="ltr">To summarize <span style="font-size:12.7272720336914px">~mapped_</span><span style="font-size:12.7272720336914px">file_region gets called when clang completes compiling every file.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">2014-12-10 23:45 GMT+02:00 Ivan Koster <span dir="ltr"><<a href="mailto:ivankoster@gmail.com" target="_blank">ivankoster@gmail.com</a>></span>:</div></div></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"><div><div class="h5"><div dir="ltr">From <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx</a><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"><span style="color:rgb(69,69,69);font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px">Mapped views of a file mapping object maintain internal references to the object, and a file mapping object does not close until all references to it are released. Therefore, to fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling </span><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/aa366882(v=vs.85).aspx" style="text-decoration:none;font-family:'Segoe UI Semibold','Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px;color:rgb(0,24,143)" target="_blank"><strong>UnmapViewOfFile</strong></a><span style="color:rgb(69,69,69);font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px"> and close the file mapping object handle by calling </span><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms724211(v=vs.85).aspx" style="text-decoration:none;font-family:'Segoe UI Semibold','Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px;color:rgb(0,24,143)" target="_blank"><strong>CloseHandle</strong></a><span style="color:rgb(69,69,69);font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px">. These functions can be called in any order.</span></blockquote><font color="#454545" face="Segoe UI, Lucida Grande, Verdana, Arial, Helvetica, sans-serif"><span style="font-size:14px;line-height:20.0060005187988px"><br></span></font>Since CloseHandle is already called after the init, it seems the mapped view is still open?<br>I'm a C and python programmer and (no C++ experience at all) have an incredible hard time reading the code.<div>Nevertheless, Mapping in mapped_file_region seems to be the only view created and it is unmapped in the destructor:<br></div><div><div><div><br><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">mapped_file_region::~mapped_file_region() {<br> if (Mapping)<br> ::UnmapViewOfFile(Mapping);<br>}</blockquote><div><br></div><div>Can I conclude that the destructor is not called?</div><div><br></div><div><br></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 6:57 AM, Kim Gräsman <span dir="ltr"><<a href="mailto:kim.grasman@gmail.com" target="_blank">kim.grasman@gmail.com</a>></span> wrote:<br><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 Reid,<br>
<br>
Yep; from Path.inc/mapped_region::init:<br>
<br>
// Close all the handles except for the view. It will keep the other handles<br>
// alive.<br>
::CloseHandle(FileMappingHandle);<br>
if (FileDescriptor) {<br>
if (CloseFD)<br>
_close(FileDescriptor); // Also closes FileHandle.<br>
} else<br>
::CloseHandle(FileHandle);<br>
return std::error_code();<br>
<br>
But as far as I can reason about it, the mapping is unmapped in<br>
~mapped_region. Maybe the MemoryBuffer backed by the mapping is cached<br>
somewhere and lives on?<br>
<span><font color="#888888"><br>
- Kim<br>
</font></span><div><div><br>
On Wed, Dec 10, 2014 at 12:27 AM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
> Can the memory mapping outlive the file handle? I bet it can.<br>
><br>
> On Tue, Dec 9, 2014 at 3:17 PM, Ivan Koster <<a href="mailto:ivankoster@gmail.com" target="_blank">ivankoster@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Ivan,<br>
>><br>
>><br>
>> Hello!<br>
>><br>
>>> 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>
>><br>
>><br>
>> I've exported the log to csv and you can find it here:<br>
>> <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><br>
>><br>
>> This is a log of sublime text opening dummy.c, commanding YCMD<br>
>> (python.exe) to analyze the dummy.c, which so and so on then finally makes<br>
>> libclang.dll open dummy.h, and finally me killing the python.exe process.<br>
>> As you can see, killing the proces does not log anything, even though it<br>
>> "frees" the file.<br>
>><br>
>> The trace shows two threads of libclang.dll (TID 6888 and TID 4040), but<br>
>> they do not operate concurrently. 4040 only starts after 6888 is done with<br>
>> dummy.h.<br>
>> When I examine the stack traces of the CreateFileMapping operation that<br>
>> appears in pairs, they both happen in the same kernel32.dll<br>
>> CreateFileMappingA function.<br>
>> So the kernel seems to work around the FILE LOCKED WITH ONLY HEADERS thing<br>
>> here?<br>
>><br>
>> There are no dangling file handles, the trace shows only pairs of open and<br>
>> close events. This is confirmed by the windows handle.exe tool, which can<br>
>> not find any filehandles to dummy.h even though the file is locked.<br>
>> The weird thing is that the windows Process Explorer has a "find file<br>
>> handle or DLL" function.<br>
>> When I make it search for dummy.h, it finds not a file handle, but a DLL<br>
>> inside python.exe called dummy.h.<br>
>> Somehow Process Explorer reports that dummy.h is loaded as a DLL? (When I<br>
>> kill python.exe this disappears).<br>
>><br>
>> I haven't dived so deep into windows stuff before so I'm hoping this<br>
>> helps!<br>
>> But to be honest, this is starting to not make sense to me. The file is<br>
>> locked even though there is no open file handle. Process Explorer reporting<br>
>> that it is loaded as a DLL...<br>
>><br>
>> Regards,<br>
>><br>
>> Ivan<br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><span class="">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div></div></div></div>