From 7ff4774e965fe934de01d51b20ad44aae2a52d8e Mon Sep 17 00:00:00 2001 From: Strahinja Val Markovic Date: Wed, 10 Apr 2013 19:45:50 -0700 Subject: [PATCH] Possible fix for random hang on Vim close Reparse would take the clang lock and then possibly call Destroy while still holding the lock. Destroy would try to take that same lock, and the mutex is not recursive. Unpleasantness ensues. I _think_ this is the root cause of #218, but I can't be sure. Such is life with threads. Fixes #218. --- cpp/ycm/ClangCompleter/TranslationUnit.cpp | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/cpp/ycm/ClangCompleter/TranslationUnit.cpp b/cpp/ycm/ClangCompleter/TranslationUnit.cpp index 78b534ca..c286c590 100644 --- a/cpp/ycm/ClangCompleter/TranslationUnit.cpp +++ b/cpp/ycm/ClangCompleter/TranslationUnit.cpp @@ -243,15 +243,18 @@ void TranslationUnit::Reparse( // param though. void TranslationUnit::Reparse( std::vector< CXUnsavedFile > &unsaved_files, uint parse_options ) { - unique_lock< mutex > lock( clang_access_mutex_ ); + int failure = 0; + { + unique_lock< mutex > lock( clang_access_mutex_ ); - if ( !clang_translation_unit_ ) - return; + if ( !clang_translation_unit_ ) + return; - int failure = clang_reparseTranslationUnit( clang_translation_unit_, - unsaved_files.size(), - &unsaved_files[ 0 ], - parse_options ); + failure = clang_reparseTranslationUnit( clang_translation_unit_, + unsaved_files.size(), + &unsaved_files[ 0 ], + parse_options ); + } if ( failure ) { Destroy(); @@ -262,9 +265,9 @@ void TranslationUnit::Reparse( std::vector< CXUnsavedFile > &unsaved_files, } -// Should only be called while holding the clang_access_mutex_ void TranslationUnit::UpdateLatestDiagnostics() { - unique_lock< mutex > lock( diagnostics_mutex_ ); + unique_lock< mutex > lock1( clang_access_mutex_ ); + unique_lock< mutex > lock2( diagnostics_mutex_ ); latest_diagnostics_.clear(); uint num_diagnostics = clang_getNumDiagnostics( clang_translation_unit_ );