Re: [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  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@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@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[jean-yves desbree via cfe-commits]

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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits