[krissn at op.pl: [Bug 241465] New: Race condition during initialization of static local variable objects]

[Andreas Pakulat]

Hi,

seems like adjusting the locking-situation is not the only design-problem
we have, see below.

Andreas

----- Forwarded message from Krzysztof Nowicki <krissn at op.pl> -----

Date: Fri, 11 Jun 2010 20:48:58 +0200 (CEST)
From: Krzysztof Nowicki <krissn at op.pl>
To: kdevelop-bugs at kdevelop.org
Subject: [Bug 241465] New: Race condition during initialization of static
	local variable objects

https://bugs.kde.org/show_bug.cgi?id=241465

           Summary: Race condition during initialization of static local
                    variable objects
           Product: kdevplatform
           Version: SVN
          Platform: Compiled Sources
        OS/Version: MS Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: kdevelop-bugs at kdevelop.org
        ReportedBy: krissn at op.pl


Version:           SVN (using KDE 4.4.3) 
OS:                MS Windows

Inside kdevplatform there are many cases where there is a global instance of a
class held as a static local variable of a function that is supposed to return
a reference to that global instance. In my case the problem occurred in
duchain.

Example:

Utils::BasicSetRepository* RecursiveImportRepository::repository() {
  static Utils::BasicSetRepository recursiveImportRepositoryObject("Recursive
Imports", &KDevelop::globalItemRepositoryRegistry());
  return &recursiveImportRepositoryObject;
}

For such variables the compiler generates a special 'guard flag', which ensures
that the constructor is called only once. This solution is however not thread
safe. In case several threads execute this function in parallel for the first
time, two things can happen (depending on the compiler):
 - GCC - the guard flag is set after the constructor is called, which means the
constructor could be executed more than once.
 - MSVC 9.0 - the guard flag is set before calling the constructor. This makes
multiple constructions less likely, but on the other hand causes the function
to return a reference to an instance, that is not yet initialized (it is being
initialized in another thread).

On MS Windows this causes a crash when duchainify is executed in multithreaded
mode. Adding a global QMutex + local QMutexLocker before the static variable
solved the problem in my case.

Reproducible: Always

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

_______________________________________________
KDevelop-bugs mailing list
KDevelop-bugs at kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-bugs


----- End forwarded message -----

-- 
You will be a winner today.  Pick a fight with a four-year-old.