Skip to content
Browse files

Fixing second reported bug in #13574 - apparently gcc overoptimizes c…

  • Loading branch information...
1 parent 5e98e17 commit a6058c0148c97178140761135931893fc6303f5b George Yunaev committed
Showing with 6 additions and 1 deletion.
  1. +6 −1 xbmc/music/karaoke/karaokelyricsmanager.cpp
7 xbmc/music/karaoke/karaokelyricsmanager.cpp
@@ -109,12 +109,15 @@ bool CKaraokeLyricsManager::Start(const CStdString & strSongPath)
void CKaraokeLyricsManager::Stop()
- CSingleLock lock (m_CritSection);
+ m_CritSection.lock();
m_karaokeSongPlaying = false;
if ( !m_Lyrics )
+ {
+ m_CritSection.unlock();
+ }
// Clean up and close karaoke window when stopping
CGUIWindowKaraokeLyrics *window = (CGUIWindowKaraokeLyrics*) g_windowManager.GetWindow(WINDOW_KARAOKELYRICS);
@@ -129,6 +132,8 @@ void CKaraokeLyricsManager::Stop()
delete m_Lyrics;
m_Lyrics = 0;
+ m_CritSection.unlock();

5 comments on commit a6058c0


this fix is disturbing, we do "CSingleLock lock (m_CritSection);" all over the place.

Team Kodi member

If gcc optimizes this out we're in real trouble. This is a typical use of the "guard pattern" and it's used all over the place. Not only MUST the constructor and the destructor be called, this is the typical way to write exception safe code and so the destructor needs to be called - in the right order - when the stack is unwound.


seriously, what exactly does this fix.

Team Kodi member

Dude, really start using PR's for this shit, especially so close to release.

Team Kodi member
Please sign in to comment.
Something went wrong with that request. Please try again.