Finding C++ static initialization order problems
Asked Answered
A

12

71

We've run into some problems with the static initialization order fiasco, and I'm looking for ways to comb through a whole lot of code to find possible occurrences. Any suggestions on how to do this efficiently?

Edit: I'm getting some good answers on how to SOLVE the static initialization order problem, but that's not really my question. I'd like to know how to FIND objects that are subject to this problem. Evan's answer seems to be the best so far in this regard; I don't think we can use valgrind, but we may have memory analysis tools that could perform a similar function. That would catch problems only where the initialization order is wrong for a given build, and the order can change with each build. Perhaps there's a static analysis tool that would catch this. Our platform is IBM XLC/C++ compiler running on AIX.

Acapulco answered 2/12, 2008 at 20:40 Comment(2)
Plus One for finding them. I filed a feature request with GCC a few years ago, but nothing ever came of it.Housing
related: stackoverflow.com/questions/29822181/…Stammel
D
83

Solving order of initialization:

First off, this is just a temporary work-around because you have global variables that you are trying to get rid of but just have not had time yet (you are going to get rid of them eventually aren't you? :-)

class A
{
    public:
        // Get the global instance abc
        static A& getInstance_abc()  // return a reference
        {
            static A instance_abc;
            return instance_abc;
        }
};

This will guarantee that it is initialised on first use and destroyed when the application terminates.

Multi-Threaded Problem:

C++11 does guarantee that this is thread-safe:

§6.7 [stmt.dcl] p4
If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.

However, C++03 does not officially guarantee that the construction of static function objects is thread safe. So technically the getInstance_XXX() method must be guarded with a critical section. On the bright side, gcc has an explicit patch as part of the compiler that guarantees that each static function object will only be initialized once even in the presence of threads.

Please note: Do not use the double checked locking pattern to try and avoid the cost of the locking. This will not work in C++03.

Creation Problems:

On creation, there are no problems because we guarantee that it is created before it can be used.

Destruction Problems:

There is a potential problem of accessing the object after it has been destroyed. This only happens if you access the object from the destructor of another global variable (by global, I am referring to any non-local static variable).

The solution is to make sure that you force the order of destruction.
Remember the order of destruction is the exact inverse of the order of construction. So if you access the object in your destructor, you must guarantee that the object has not been destroyed. To do this, you must just guarantee that the object is fully constructed before the calling object is constructed.

class B
{
    public:
        static B& getInstance_Bglob;
        {
            static B instance_Bglob;
            return instance_Bglob;;
        }

        ~B()
        {
             A::getInstance_abc().doSomthing();
             // The object abc is accessed from the destructor.
             // Potential problem.
             // You must guarantee that abc is destroyed after this object.
             // To guarantee this you must make sure it is constructed first.
             // To do this just access the object from the constructor.
        }

        B()
        {
            A::getInstance_abc();
            // abc is now fully constructed.
            // This means it was constructed before this object.
            // This means it will be destroyed after this object.
            // This means it is safe to use from the destructor.
        }
};
Duet answered 2/12, 2008 at 22:51 Comment(23)
I don't get to get rid of them. I didn't create them. I'm just stuck with the task of finding them. As far as I know, they are all const objects, which isn't quite so bad.Acapulco
Double-checked locking works just fine in C++. It is not guaranteed to work, but in practice it does. There is a difference between the two.Chilt
@coryan, @Martin York: Not only sequence points, but things like CPU instruction reordering, speculative execution, and cache line invalidation across multiple CPUs. Use a thread API, its the only way to be sure.Later
Neat trick to enforce the lifetime. Note that if we went DI we would have: B(A&) which would neatly solve the issue. Of course not being default constructable has its own woes so perhaps B(): mInstanceOfA(A::getInstance()) {}Shcherbakov
@coryan: you forgot to add "..until it breaks".Chas
This just moves the problem to the destructors. Been there, done that, got the tee-short and the crash when one object was destroyed too soon at program exit.Housing
@jww: You should read then. Because we guarantee the order of construction and destruction so there is no problem. That is the point.Duet
We must have different meanings of the word "problem" then. I'd call a crash a problem....Housing
@jww: Then you must be doing it wrong. Rered until you understand how C++ works :-) OK sorry being an ass. Its easy to do it wrong. But I have found that this problem is simple to fix because of the guarantees of the language. Of course you can still get it binds. But the simplest solution is obviously to not use globals (or static storage duration variables).Duet
@Loki - thanks. I believe I have a pretty good understanding of it. Perhaps you can update your answer to address the order of destruction across translation units?Housing
@jww. It already handles that. Which was the point of writing this answer. It enforces an order of construction and destruction across all static storage duration objects. Though it requires you to do a tiny bit of work. This is simply a workaround for bad programming practice where you have globals but it guarantees that all objects are created and destroyed in a well defined order. Which means the interactions are well defined.Duet
Forgive my ignorance... How, exactly, do you do this across translation units?: "Solution you must make sure you force the order of destruction..."Housing
Read the comments inside the code above. The order of destruction is the exact inverse of the order of destruction (guaranteed by the language). So all you need to do is create them in the correct order. You can do that by using the well known pattern to access the object in the constructor.Duet
"C++03 does not officially guarantee that the construction of static function objects is thread safe". Well, it doesn't acknowledge the existence of multithreading at all.Expertise
@Deduplicator: And hence it does not provide any guarantee that construction is thread safe.Duet
Yes, I know that, but the way you say it, it looks like you are saying "C++03 knows threads, but for some no doubt asinine reason they didn't make that construct thread-safe" instead of "C++03 does not know threads, so you are on your own. Use ..."Expertise
@Loki Worth noting this order of destruction does not apply to thread locals which are accessing a normal static var.Gushy
Nit-picking: regarding destruction, the concern with this solution is that all clients of A (such as B::instance) must call A::getInstance() in their constructor if they wish to use A::getInstance() in their destructor. I agree that in most situations, this occurs naturally, but there are cases where it might not. In fact, I believe this is why logging mechanisms (such as std::cout) are typically implemented using the Nifty Counter idiom: this allows a class B to perform logging only on destruction, which would be unsafe if the logger was implemented as in this answer.Vinitavinn
See also isocpp.org/wiki/faq/ctors#construct-on-first-use-v2 : However if a and/or b and/or c fail to use ans in their constructors and/or if any code anywhere gets the address of ans and hands it to some other static object, all bets are off and you have to be very, very careful.Vinitavinn
"There is a potential problem of accessing the object after it has been destroyed. This only happens if you access the object from the destructor of another global variable" Please bro, Can you provide an example of how this problem can happen?Kone
@AccessDenied I do above. With the solution. In the class B above remove the call to A::getInstance_abc(); from the constructor and you now have a "potential" issue.Duet
@MartinYork, Oh thanks, I got it: the problem will happen if we call a member function getInstance().doSomthing() in the destructor of this object, and at this moment getInstance() hasn't been constructed yet. So the Fix: construct getInstance() first in the constructor of this object.Kone
Just answer me if possible; if I am having static object 'a' and 'b' constructed respectively, now if 'a' destructed before 'b', regardless of how this can happen. Does the program is ill-formed.Kone
C
32

I just wrote a bit of code to track down this problem. We have a good size code base (1000+ files) that was working fine on Windows/VC++ 2005, but crashing on startup on Solaris/gcc. I wrote the following .h file:

#ifndef FIASCO_H
#define FIASCO_H

/////////////////////////////////////////////////////////////////////////////////////////////////////
// [WS 2010-07-30] Detect the infamous "Static initialization order fiasco"
// email warrenstevens --> [initials]@[firstnamelastname].com 
// read --> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 if you haven't suffered
// To enable this feature --> define E-N-A-B-L-E-_-F-I-A-S-C-O-_-F-I-N-D-E-R, rebuild, and run
#define ENABLE_FIASCO_FINDER
/////////////////////////////////////////////////////////////////////////////////////////////////////

#ifdef ENABLE_FIASCO_FINDER

#include <iostream>
#include <fstream>

inline bool WriteFiasco(const std::string& fileName)
{
    static int counter = 0;
    ++counter;

    std::ofstream file;
    file.open("FiascoFinder.txt", std::ios::out | std::ios::app);
    file << "Starting to initialize file - number: [" << counter << "] filename: [" << fileName.c_str() << "]" << std::endl;
    file.flush();
    file.close();
    return true;
}

// [WS 2010-07-30] If you get a name collision on the following line, your usage is likely incorrect
#define FIASCO_FINDER static const bool g_psuedoUniqueName = WriteFiasco(__FILE__);

#else // ENABLE_FIASCO_FINDER
// do nothing
#define FIASCO_FINDER

#endif // ENABLE_FIASCO_FINDER

#endif //FIASCO_H

and within every .cpp file in the solution, I added this:

#include "PreCompiledHeader.h" // (which #include's the above file)
FIASCO_FINDER
#include "RegularIncludeOne.h"
#include "RegularIncludeTwo.h"

When you run your application, you will get an output file like so:

Starting to initialize file - number: [1] filename: [p:\\OneFile.cpp]
Starting to initialize file - number: [2] filename: [p:\\SecondFile.cpp]
Starting to initialize file - number: [3] filename: [p:\\ThirdFile.cpp]

If you experience a crash, the culprit should be in the last .cpp file listed. And at the very least, this will give you a good place to set breakpoints, as this code should be the absolute first of your code to execute (after which you can step through your code and see all of the globals that are being initialized).

Notes:

  • It's important that you put the "FIASCO_FINDER" macro as close to the top of your file as possible. If you put it below some other #includes you run the risk of it crashing before identifying the file that you're in.

  • If you're using Visual Studio, and pre-compiled headers, adding this extra macro line to all of your .cpp files can be done quickly using the Find-and-replace dialog to replace your existing #include "precompiledheader.h" with the same text plus the FIASCO_FINDER line (if you check off "regular expressions, you can use "\n" to insert multi-line replacement text)

Coniah answered 4/8, 2010 at 2:42 Comment(3)
This seems helpful for small projects. Unfortunately for me I have a codebase of 1000s of implementation files, and hundreds of thousands of lines of code :/Dissolution
Chad - There is often a way to make a quick replacement, even on 1000+ files (e.g. if you already have precompiled headers, you can search/replace on that header name, or write a small script to do the replacement on all the files). I did the former on our project and it had many 100s of files.Coniah
@Dissolution With a good grep tool, like grepWin, one could do this with regular expressions. Replace [\s\S]* (entire file) with #include "HeaderContainingTheMacro.h"\nFIASCO_FINDER\n$0 for all your *.cpp/cxx/cc files. The $0 is to put back the entire file after having placed your preamble.Skintight
C
15

Depending on your compiler, you can place a breakpoint at the constructor initialization code. In Visual C++, this is the _initterm function, which is given a start and end pointer of a list of the functions to call.

Then step into each function to get the file and function name (assuming you've compiled with debugging info on). Once you have the names, step out of the function (back up to _initterm) and continue until _initterm exits.

That gives you all the static initializers, not just the ones in your code - it's the easiest way to get an exhaustive list. You can filter out the ones you have no control over (such as those in third-party libraries).

The theory holds for other compilers but the name of the function and the capability of the debugger may change.

Cotidal answered 2/12, 2008 at 21:57 Comment(0)
C
5

perhaps use valgrind to find usage of uninitialized memory. The nicest solution to the "static initialization order fiasco" is to use a static function which returns an instance of the object like this:

class A {
public:
    static X &getStatic() { static X my_static; return my_static; }
};

This way you access your static object is by calling getStatic, this will guarantee it is initialized on first use.

If you need to worry about order of de-initialization, return a new'd object instead of a statically allocated object.

EDIT: removed the redundant static object, i dunno why but i mixed and matched two methods of having a static together in my original example.

Commuter answered 2/12, 2008 at 20:51 Comment(8)
this answer is fine. and de-initialization is also guarenteed: it's the reverse of the completion of the constructors, also across translation units. so all is fine then i think. it won't leak evenStalinist
@litb, the C++ FAQ Lite seems to disagree with you on destruction order. See parashift.com/c++-faq-lite/ctors.html#faq-10.12. You know the standard well -- is there something in there that proves Marshall Cline wrong? 8v)Acapulco
I think the issue with using the static object ref is you can end up with references to dead object during program termination.Commuter
@Evan, I think something is not right in your example. The getStatic() method returns a value, but it seems to have nothing to do with the something_static member. Does something_static have a purpose?Acapulco
This way you access A::something_static by calling getStatic << yeah i don't get that too :/. either you go with A::something_static, or you go with calling getStatic(); and use what it returns i thinkStalinist
OOPs! i was thinking of 2 different things when I typed that, fixed now.Commuter
arg. please forget about my comment above. i messed up. "if x in its ctor calls y::get().foo(); then y's ctor will finish before x' ctor. this means that y will be destructed before x, since y's ctor finished before x ones." < indeed i mean the other way: y will be destructed after x.Stalinist
i removed my comments to not confuse the matter even more. see martin's fine answer.Stalinist
J
5

There is code that essentially "initializes" C++ that is generated by the compiler. An easy way to find this code / the call stack at the time is to create a static object with something that dereferences NULL in the constructor - break in the debugger and explore a bit. The MSVC compiler sets up a table of function pointers that is iterated over for static initialization. You should be able to access this table and determine all static initialization taking place in your program.

Josselyn answered 11/1, 2011 at 15:1 Comment(0)
F
4

We've run into some problems with the static initialization order fiasco, and I'm looking for ways to comb through a whole lot of code to find possible occurrences. Any suggestions on how to do this efficiently?

It's not a trivial problem but at least it can done following fairly simple steps if you have an easy-to-parse intermediate-format representation of your code.

1) Find all the globals that have non-trivial constructors and put them in a list.

2) For each of these non-trivially-constructed objects, generate the entire potential-function-tree called by their constructors.

3) Walk through the non-trivially-constructor function tree and if the code references any other non-trivially constructed globals (which are quite handily in the list you generated in step one), you have a potential early-static-initialization-order issue.

4) Repeat steps 2 & 3 until you have exhausted the list generated in step 1.

Note: you may be able to optimize this by only visiting the potential-function-tree once per object class rather than once per global instance if you have multiple globals of a single class.

Fico answered 5/5, 2009 at 22:23 Comment(0)
F
1

Replace all the global objects with global functions that return a reference to an object declared static in the function. This isn't thread-safe, so if your app is multi-threaded you might need some tricks like pthread_once or a global lock. This will ensure that everything is initialized before it is used.

Now, either your program works (hurrah!) or else it sits in an infinite loop because you have a circular dependency (redesign needed), or else you move on to the next bug.

Formidable answered 2/12, 2008 at 20:52 Comment(0)
E
1

The first thing you need to do is make a list of all static objects that have non-trivial constructors.

Given that, you either need to plug through them one at a time, or simply replace them all with singleton-pattern objects.

The singleton pattern comes in for a lot of criticism, but the lazy "as-required" construction is a fairly easy way to fix the majority of the problems now and in the future.

old...

MyObject myObject

new...

MyObject &myObject()
{
  static MyObject myActualObject;
  return myActualObject;
}

Of course, if your application is multi-threaded, this can cause you more problems than you had in the first place...

Eigenvalue answered 2/12, 2008 at 20:53 Comment(5)
It's not the singelton pattern. It has a similar implementation but it is not the same thing.Duet
Scott Meyers told me it was ;-) [effective C++, 2nd ed, P 222]Eigenvalue
I call the above 'construct on first use' pattern. Just to clarify, singleton pattern ensures a class has only one instance and provides a global point of access to it. 'Construct on first use' is/can be the part that provides 'a global point of access' part of the impementation of a singleton. However, on its own, doesn't ensure a single instance.Nobel
How is this fixing the problem? Does this give a defined init/deinit ordering?Hermie
@Hermie - 'construct on first use' above means that your object can't be used before its constructed. (typical problem would be two global objects in separate compilation units). And they're destructed in the reverse order, so yes, the order is defined.Eigenvalue
G
1

Gimpel Software (www.gimpel.com) claims that their PC-Lint/FlexeLint static analysis tools will detect such problems.

I have had good experience with their tools, but not with this specific issue so I can't vouch for how much they would help.

Gamic answered 5/5, 2009 at 22:34 Comment(0)
S
1

Some of these answers are now out of date. For the sake of people coming from search engines, like myself:

On Linux and elsewhere, finding instances of this problem is possible through Google's AddressSanitizer.

AddressSanitizer is a part of LLVM starting with version 3.1 and a part of GCC starting with version 4.8

You would then do something like the following:

$ g++ -fsanitize=address -g staticA.C staticB.C staticC.C -o static 
$ ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./static 
=================================================================
==32208==ERROR: AddressSanitizer: initialization-order-fiasco on address ... at ...
    #0 0x400f96 in firstClass::getValue() staticC.C:13
    #1 0x400de1 in secondClass::secondClass() staticB.C:7
    ...

See here for more details: https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco

Scilicet answered 24/10, 2019 at 12:39 Comment(0)
C
0

If your project is in Visual Studio (I've tried this with VC++ Express 2005, and with Visual Studio 2008 Pro):

  1. Open Class View (Main menu->View->Class View)
  2. Expand each project in your solution and Click on "Global Functions and Variables"

This should give you a decent list of all of the globals that are subject to the fiasco.

In the end, a better approach is to try to remove these objects from your project (easier said than done, sometimes).

Coniah answered 22/7, 2010 at 2:32 Comment(1)
Thanks, but you'll see in my question that our platform is IBM XL C/C++ under AIX. Visual Studio isn't an option. I agree it'd be best to get rid of them; the challenge is finding them all.Acapulco
P
0

Other answers are correct, I just wanted to add that the object's getter should be implemented in a .cpp file and it should not be static. If you implement it in a header file, the object will be created in each library / framework you call it from....

Pronominal answered 28/6, 2011 at 9:24 Comment(1)
Doesn't the one-definition-rule prevent this from happening?Daye

© 2022 - 2024 — McMap. All rights reserved.