Object linking order causes Segmentation fault???

The_Nerd · 11-03-2005, 10:38 PM

Take a look at my source. I have 3 source files here that get compiled as object files and then all linked together. Explaination of my problem follows source.

script.cpp

Code:

list<LS_RegisterFunction *> LS_RegisterFunction::gs_RegisteredFuncs;

script.h

Code:

class LS_RegisterFunction
{
	public:
		static list<LS_RegisterFunction *> gs_RegisteredFuncs;
		string Name;
		lua_CFunction FuncPtr;
		
		LS_RegisterFunction(char *cpName, lua_CFunction Ptr)
		{
			this->Name = cpName;
			this->FuncPtr = Ptr;
			LS_RegisterFunction::gs_RegisteredFuncs.push_back(this);
		}
		~LS_RegisterFunction()
		{
			this->gs_RegisteredFuncs.remove(this);
		}
};

test.cpp

Code:

class Test
{
    public:
        int iTestInt;
};

int MyFunc(lua_State *LuaState);
LS_RegisterFunction TestPtr("MyFunc", MyFunc);
int MyFunc(lua_State *LuaState)
{
}

main.cpp

Code:

int main(etc...)
{
    etc...
    /* Register all functions to Lua in gs_RegisteredFuncs */
    etc...
}

I have a macro called LUA_REGISTERED_FUNCTION, like so:

Code:

#define LUA_REGISTERED_FUNCTION(Name) \
int LuaScriptFunction_ ## Name (lua_State *LuaState); \
LS_RegisterFunction LuaScriptFunctionPtr_ ## Name ( #Name, LuaScriptFunction_ ## Name); \
int LuaScriptFunction_ ## Name (lua_State *LuaState)

This way, I can simply create a function in Lua like this:

Code:

LUA_REGISTERED_FUNCTION(HelloWorld)
{
    lua_pushstring("Hello world!");
    return 1;
}

All that is to say:
If I compile and link the 3 object files above (script.o, test.o, main.o) then it causes a Segmentation fault IF I link in this order: main.o, script.o, test.o (e.g. g++ -o mytest main.o script.o test.o -llua -llualib)

However, if I link the object files in the order: main.o, test.o, script.o then the Segmentation fault goes away, and the program runs fine. Why is this? I am just going to link in the right order for now, but I would like to now why, and possibly how to work around it.

By the way, I did some tests, and gs_RegisteredFuncs doesn't exists in the LS_RegisterFunction contructer if I link the object files as in example 1 (main, script, test). This tells me that the global variable isn't being created before the constructor gets called. But I thought it wasn't possible for a class to call it's constructor while static members weren't created yet?

naf · 11-03-2005, 11:26 PM

TestPtr seems to be a global variable. You have no guarantee that this global variable will be instantiated after the static variable of the class it uses. You should avoid these types of global variables because it causes a race-condition in which object (the global list<LS_RegisterFunction *> LS_RegisterFunction::gs_RegisteredFuncs or LS_RegisterFunction TestPtr("MyFunc", MyFunc);
the latter using the former!

The C++ standard is clear about this situation too. You were just fortunate enought that the compiler instantiated them in the order you specified the object files.

(page 217 of Stroustrup's '`"The C++ Programming Language 3rd Ed" states:

Quote:

There is no guaranteed order of initialization of global variables in different translation units. Consequently, it is unwise to create order dependencies between initializer of global variables in different compilation units. In addition, it i no possible to catch an exception thrown by the initializer of a global variable. It is generally best to minimize the use of global variables and in particular to limit the use of global variables requiring comples initialization.
....
Often, a function returning a reference is a good alternative to a global variable.

where translation units includes global variables.)
The only safe exception is globals needing usage of the standard library.