[cfe-dev] libclang locking files for write/delete on windows
Ivan Koster
ivankoster at gmail.com
Tue Dec 9 15:17:28 PST 2014
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141210/2302b145/attachment.html>
More information about the cfe-dev
mailing list