[Qt-creator] Qt Creator 4.11 frequently becomes non-responsive

[Nikolai Kosjar]

On 12/22/19 2:06 AM, Adam Light wrote:
> 
> On Sat, Dec 21, 2019 at 4:30 PM Dmitry Volosnykh 
> <dmitry.volosnykh at gmail.com <mailto:dmitry.volosnykh at gmail.com>> wrote:
> 
>     Hi Adam, there's somewhat similar issue filed in Jira:
>     https://bugreports.qt.io/browse/QTCREATORBUG-23336
>     Initially, it is focused on macOS, but maybe you will find your
>     experiences the same, then the status of this issue might be changed
>     to a wider scope.
> 
> 
> Dmitry, thanks for the link, but I think that's a completely separate 
> problem. I'm actually not doing any debugging at all--I'm not even 
> running the application, just editing code and rebuilding.
> 
> Here is part of a stack trace I recorded. I clicked the X to close a 
> single file and Creator hung for 5 or more seconds. I was able to record 
> a trace the tail end of that hang, and here is the stack trace for the 
> Creator thread taking most of the time. The time column on the left is 
> in seconds.
> 
> 1.7382851   |- ntdll.dll!RtlUserThreadStart
> 1.7382851   |    kernel32.dll!BaseThreadInitThunk
> 1.7382851   |    Qt5Core.dll!<PDB not found>
> 1.7382851   |    Qt5Core.dll!<PDB not found>
> 1.7382851   |   CppTools4.dll!Utils::Internal::AsyncJob<void,void 
> (__cdecl&)(QFutureInterface<void> & 
> __ptr64,QSharedPointer<CppTools::BaseEditorDocumentParser>,CppTools::BaseEditorDocumentParser::UpdateParams),QSharedPointer<CppTools::BaseEditorDocumentParser>,CppTools::BaseEditorDocumentParser::UpdateParams 
> const & __ptr64>::run
> 1.7382851   |   
>   CppTools4.dll!CppTools::BaseEditorDocumentProcessor::runParser
> 1.7372606   |    |- CppTools4.dll!CppTools::BaseEditorDocumentParser::update
> 1.7372606   |    |   
>   CppTools4.dll!CppTools::BuiltinEditorDocumentParser::updateImpl
> 1.7176022   |    |    |- 
> CppTools4.dll!CppTools::Internal::CppSourceProcessor::run
> 1.7176022   |    |    |   
>   CppTools4.dll!CppTools::Internal::CppSourceProcessor::sourceNeeded
> 1.7176022   |    |    |    CPlusPlus4.dll!CPlusPlus::Preprocessor::run
> 1.7176022   |    |    |   
>   CPlusPlus4.dll!CPlusPlus::Preprocessor::preprocess
> 1.7176022   |    |    |    CPlusPlus4.dll!CPlusPlus::Preprocessor::lex
> 1.7176022   |    |    |   
>   CPlusPlus4.dll!CPlusPlus::Preprocessor::handlePreprocessorDirective
> 1.7176022   |    |    |   
>   CPlusPlus4.dll!CPlusPlus::Preprocessor::handleIncludeDirective
> 1.7176022   |    |    |   
>   CppTools4.dll!CppTools::Internal::CppSourceProcessor::sourceNeeded
> 1.7176022   |    |    |    CPlusPlus4.dll!CPlusPlus::Preprocessor::run
> 1.7176022   |    |    |   
>   CPlusPlus4.dll!CPlusPlus::Preprocessor::preprocess

Apparently the built-in preprocessor does some heavy work.

Closing the document should abort the preprocessor at the next #include 
directive it encounters. Until then, the UI blocks. In your case, it 
seems to take too much time until this point is reached.

Does your small file includes some insanely (possibly code-generated) 
huge header file?

You could try to make use of:

   Menu: Tools > Options > C++ > Code Model
     [x] Do not index files greater than _1MB_

This setting might explain the difference between your setups.

Nikolai