[cfe-dev] libclang locking files for write/delete on windows

Kim Gräsman kim.grasman at gmail.com
Tue Dec 9 21:57:15 PST 2014


Hi Reid,

Yep; from Path.inc/mapped_region::init:

  // Close all the handles except for the view. It will keep the other handles
  // alive.
  ::CloseHandle(FileMappingHandle);
  if (FileDescriptor) {
    if (CloseFD)
      _close(FileDescriptor); // Also closes FileHandle.
  } else
    ::CloseHandle(FileHandle);
  return std::error_code();

But as far as I can reason about it, the mapping is unmapped in
~mapped_region. Maybe the MemoryBuffer backed by the mapping is cached
somewhere and lives on?

- Kim

On Wed, Dec 10, 2014 at 12:27 AM, Reid Kleckner <rnk at google.com> wrote:
> Can the memory mapping outlive the file handle? I bet it can.
>
> On Tue, Dec 9, 2014 at 3:17 PM, Ivan Koster <ivankoster at gmail.com> wrote:
>>>
>>> Hi Ivan,
>>
>>
>> Hello!
>>
>>> This is good info; MemoryBuffer::getOpenFile conditionally uses file
>>> mappings or normal file reads depending on file size (see
>>> MemoryBuffer.cpp/shouldUseMmap).
>>>
>>> Since the mapping uses a stricter sharing mode than the normal file
>>> read, it's more likely to fail. Still not sure who's writing/deleting
>>> the file while Clang attempts to map it, can you make that out from
>>> your PM logs?
>>
>>
>> I've exported the log to csv and you can find it here:
>> https://drive.google.com/file/d/0B8xFlIzMhHcpdzR6OW4wM3BZdGM/view?usp=sharing
>>
>> 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.
>> As you can see, killing the proces does not log anything, even though it
>> "frees" the file.
>>
>> 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.
>> When I examine the stack traces of the CreateFileMapping operation that
>> appears in pairs, they both happen in the same kernel32.dll
>> CreateFileMappingA function.
>> So the kernel seems to work around the FILE LOCKED WITH ONLY HEADERS thing
>> here?
>>
>> 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.
>> The weird thing is that the windows Process Explorer has a "find file
>> handle or DLL" function.
>> When I make it search for dummy.h, it finds not a file handle, but a DLL
>> inside python.exe called dummy.h.
>> Somehow Process Explorer reports that dummy.h is loaded as a DLL? (When I
>> kill python.exe this disappears).
>>
>> I haven't dived so deep into windows stuff before so I'm hoping this
>> helps!
>> 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...
>>
>> Regards,
>>
>> Ivan
>
>



More information about the cfe-dev mailing list