возможно, используйте valgrind, чтобы найти использование неинициализированной памяти. Лучшее решение "фиаско статического порядка инициализации" - использовать статическую функцию, которая возвращает экземпляр объекта, подобный этому:

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

Таким образом, вы получаете доступ к своему статическому объекту, вызывая getStatic, это гарантирует, что он инициализируется при первом использовании.

Если вам нужно беспокоиться о порядке деинициализации, верните новый объект вместо статически выделенного объекта.

Обновлено: удалил избыточный статический объект, я не знаю, почему, но я смешал и сопоставил два метода создания статического вместе в моем исходном примере.

Замените все глобальные объекты глобальными функциями, которые возвращают ссылку на объект, объявленный статическим в функции. Это не является поточно-ориентированным, поэтому, если ваше приложение многопоточное, вам могут понадобиться некоторые уловки, такие как pthread_once или глобальная блокировка. Это гарантирует, что все будет инициализировано перед использованием.

Теперь либо ваша программа работает (ура!), Либо она находится в бесконечном цикле, потому что у вас есть циклическая зависимость (требуется редизайн), либо вы переходите к следующей ошибке.

Первое, что вам нужно сделать, это составить список всех статических объектов, имеющих нетривиальные конструкторы.

Учитывая это, вам нужно либо подключать их по одному, либо просто заменять их все объектами одноэлементного шаблона.

Шаблон singleton вызывает много критики, но ленивое построение "по мере необходимости" - довольно простой способ исправить большинство проблем сейчас и в будущем.

Старый...

MyObject myObject

новый...

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

Конечно, если ваше приложение многопоточное, это может вызвать у вас больше проблем, чем было изначально ...

В зависимости от вашего компилятора вы можете разместить точку останова в коде инициализации конструктора. В Visual C++ это функция _initterm, которой даны указатели начала и конца списка функций, которые необходимо вызвать.

Затем перейдите к каждой функции, чтобы получить имя файла и функцию (при условии, что вы скомпилировали с включенной отладочной информацией). Когда у вас есть имена, выйдите из функции (вернитесь к _initterm) и продолжайте, пока _initterm не выйдет.

Это дает вам все статические инициализаторы, а не только те, которые есть в вашем коде - это самый простой способ получить исчерпывающий список. Вы можете отфильтровать те, которые не можете контролировать (например, в сторонних библиотеках).

Теория верна для других компиляторов, но имя функции и возможности отладчика могут измениться.

Порядок решения инициализации:

Во-первых, это всего лишь временный обходной путь, потому что у вас есть глобальные переменные, от которых вы пытаетесь избавиться, но просто еще не успели (вы собираетесь избавиться от них в конце концов, не так ли? :-)

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

Это гарантирует, что он инициализируется при первом использовании и уничтожается при завершении работы приложения.

Многопоточная проблема:

C++ 11 делает гарантирует, что это потокобезопасный:

§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.

Однако в C++ 03 нет официально гарантирует, что создание статических функциональных объектов является потокобезопасным. Так что технически метод getInstance_XXX() должен быть защищен критической секцией. С другой стороны, gcc имеет явный патч как часть компилятора, который гарантирует, что каждый объект статической функции будет инициализирован только один раз даже при наличии потоков.

Обратите внимание: Не использует дважды проверенный шаблон запирания, чтобы попытаться избежать затрат на блокировку. Это не будет работать в C++ 03.

Проблемы создания:

При создании нет проблем, потому что мы гарантируем, что он будет создан до того, как его можно будет использовать.

Проблемы разрушения:

Существует потенциальная проблема доступа к объекту после его уничтожения. Это происходит только в том случае, если вы обращаетесь к объекту из деструктора другой глобальной переменной (под глобальной я имею в виду любую нелокальную статическую переменную).

Решение состоит в том, чтобы убедиться, что вы принудительно устанавливаете порядок уничтожения. Помните, что порядок разрушения прямо противоположен порядку построения. Поэтому, если вы обращаетесь к объекту в своем деструкторе, вы должны гарантировать, что объект не был уничтожен. Для этого вы должны просто гарантировать, что объект полностью построен до того, как будет создан вызывающий объект.

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.
        }
};

We've run into some problems with thestatic initialization order fiasco,and I'm looking for ways to combthrough a whole lot of code to findpossible occurrences. Any suggestionson how to do this efficiently?

Это нетривиальная проблема, но, по крайней мере, это можно сделать, выполнив довольно простые шаги, если у вас есть легко анализируемое представление вашего кода в промежуточном формате.

1) Найдите все глобальные объекты, у которых есть нетривиальные конструкторы, и поместите их в список.

2) Для каждого из этих нетривиально сконструированных объектов сгенерируйте все дерево потенциальных функций, вызываемое их конструкторами.

3) Пройдитесь по дереву функций нетривиального конструктора, и если код ссылается на любые другие нетривиально сконструированные глобальные объекты (которые довольно удобно находятся в списке, который вы создали на первом шаге), у вас есть потенциальный порядок ранней статической инициализации проблема.

4) Повторяйте шаги 2 и 3, пока не исчерпаете список, созданный на шаге 1.

Примечание: вы можете оптимизировать это, посетив дерево потенциальных функций только один раз для каждого класса объекта, а не один раз для каждого глобального экземпляра, если у вас есть несколько глобальных объектов одного класса.

Gimpel Software (www.gimpel.com) утверждает, что их инструменты статического анализа PC-Lint / FlexeLint обнаруживают такие проблемы.

У меня был хороший опыт работы с их инструментами, но не с этой конкретной проблемой, поэтому я не могу поручиться за то, насколько они помогут.

Если ваш проект находится в Visual Studio (я пробовал это с VC++ Express 2005 и с Visual Studio 2008 Pro):

1. Открыть представление класса (Главное меню-> Просмотр-> Просмотр класса)
2. Разверните каждый проект в своем решении и нажмите «Глобальные функции и переменные».

Это должно дать вам достойный список всех глобальных объектов, на которые распространяется фиаско.

В конце концов, лучший подход - попытаться удалить эти объекты из вашего проекта (иногда проще сказать, чем сделать).

Я просто написал немного кода, чтобы отследить эту проблему. У нас есть кодовая база хорошего размера (более 1000 файлов), которая отлично работала в Windows / VC++ 2005, но вылетала при запуске в Solaris / gcc. Я написал следующий файл .h:

#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

и в файле каждый .cpp в решении я добавил это:

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

Когда вы запустите приложение, вы получите такой выходной файл:

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]

Если произошел сбой, виновник должен быть в последнем указанном файле .cpp. И, по крайней мере, это даст вам хорошее место для установки точек останова, поскольку этот код должен быть абсолютный первый вашего кода для выполнения (после чего вы можете пройти через свой код и увидеть все глобальные переменные, которые инициализируются).

Заметки:

• Важно, чтобы вы поместили макрос «FIASCO_FINDER» как можно ближе к началу файла. Если вы поместите его под другим #includes, вы рискуете его сбой, прежде чем идентифицировать файл, в котором вы находитесь.

• Если вы используете Visual Studio и предварительно скомпилированные заголовки, добавление этой дополнительной строки макроса в все ваших файлов .cpp можно быстро выполнить с помощью диалогового окна «Найти и заменить», чтобы заменить существующий #include "precompiledheader.h" на тот же текст плюс строка FIASCO_FINDER (если вы отметите «регулярные выражения, вы можете использовать« \ n »для вставки многострочного замещающего текста)

Есть код, который, по сути, «инициализирует» C++, генерируемый компилятором. Простой способ найти этот код / ​​стек вызовов в то время - создать статический объект с чем-то, что разыменовывает NULL в конструкторе - отключите отладчик и немного исследуйте. Компилятор MSVC создает таблицу указателей функций, которая повторяется для статической инициализации. У вас должна быть возможность получить доступ к этой таблице и определить все статические инициализации, происходящие в вашей программе.

Другие ответы верны, я просто хотел добавить, что получатель объекта должен быть реализован в файле .cpp и не должен быть статическим. Если вы реализуете его в файле заголовка, объект будет создан в каждой библиотеке / фреймворке, из которого вы его вызываете ....

Некоторые из этих ответов уже устарели. Ради людей из поисковых систем, таких как я:

В Linux и других системах найти экземпляры этой проблемы можно с помощью Google AddressSanitizer.

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

Затем вы должны сделать что-то вроде следующего:

$ 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
    ...

Подробнее см. Здесь: https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco