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 <kli...@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@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
