[A fix related to closing C++ header file descriptors on windows]

[jean-yves desbree via cfe-commits]

Hi Manuel,

I had forgotten this point and I see your mail only now...
Thanks for your interest.

I did not evaluate this issue with a newer release of clang (issue seen in
3.6.2)

However, it seems that other people still have this kind of issue for
several months.
https://bugreports.qt.io/browse/QTCREATORBUG-15449
So I imagine it would be worth seeing if it is related.

Since I did this patch, I never had again the lock on the H files.
And I use qtcreator with clang as my everyday c++ IDE.
So it seems to be a good candidate.

An IDE is more sensitive to leaks than a compiler / analyzer as it keeps
the files open on a longer duration.
So it may explain why nobody else complains.

Thanks,
Jean-Yves



On Wed, Apr 27, 2016 at 1:54 PM, Manuel Klimek <klimek at google.com> wrote:

> Stumbling over this (much too late, of course), is this still a problem
> for you?
>
> On Thu, Nov 26, 2015 at 5:01 PM jean-yves desbree via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>> I use clang 3.6.2 with qt creator 3.5.1 on windows 7 for parsing code in
>> this IDE.
>> It works well.
>>
>> However, I can see that clang keeps a few times some file descriptors
>> opened on c++ header files (h files) after having parsed a cpp file (that
>> includes these h files).
>> The effect is that we cannot save these h files, what is quite
>> frustrating when using an IDE.
>>
>> After debugging clang, I remarked that there was a file descriptor leak
>> in the method Preprocessor::HandleIncludeDirective
>> (file tools/clang/lib/Lex/PPDirectives.cpp)
>>
>> The object 'FileEntry *File' is created (for a given h file) and after
>> some checks, the regular treatment calls EnterSourceFile.
>> The File object is detroyed during this call (quite deeply in the stack)
>>
>> However, when some errors occur, the execution path goes through early
>> returns and other code pathes.
>> In this case, the file descriptor associated to File is not closed and
>> the file descriptor remains open.
>>
>> So I did a correction that uses RAII in order to have the file descriptor
>> closed.
>> So I wrapped 'FileEntry *File' in a dedicated 'FileEntryCloser
>> fileEntryCloser(File)'
>>
>> On regular treatment, the closer is released:
>>   // If all is good, enter the new file!
>>   if (EnterSourceFile(FID, CurDir, FilenameTok.getLocation()))
>>   {
>>      fileEntryCloser.release();
>>      return;
>>   }
>>
>> Otherwise, the file descriptor is closed
>>    ~FileEntryCloser()
>>    {
>>       if(m_File)
>>          m_File->closeFile();
>>    }
>>
>>
>> Now, I have no more remaining file descriptors ...
>> Would it be possible to have an evaluation on that?
>>
>> Thanks in advance.
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160609/7db13bd8/attachment.html>