Linux port: c++ static initialization issues
by Carsten Tusk · in Torque 3D Professional · 02/19/2010 (1:56 pm) · 8 replies
I am playing around with a OSX to Linux port of the 1.0.1 release for a dedicated server, I got the whole thing to build properly at this point, however I am running into what seems to be issues in static initialization order.
What I find curious is that neither the windows nor the OSX build are having these issues, I am only seeing them on the linux build ( gcc version 4.2.4 or 4.4.1, no difference ).
Has anyone ever encountered this before?
Here is an example backtrace, there are more, I resolved two but each time I resolve one I keep running into the next. Given that they do not exist in the other platform builds I am hoping for a simpler solution than to rewrite initialization code throughout the codebase.
Program received signal SIGSEGV, Segmentation fault.
0x08225114 in String::StringData::isInterned (this=0x0) at ../../../../Engine/source/core/util/str.cpp:374
374 return mIsInterned;
(gdb) bt
#0 0x08225114 in String::StringData::isInterned (this=0x0) at ../../../../Engine/source/core/util/str.cpp:374
#1 0x08221271 in String::isInterned (this=0x8c9abe0) at ../../../../Engine/source/core/util/str.cpp:604
#2 0x0822250a in String::intern (this=0x8c9abe0) at ../../../../Engine/source/core/util/str.cpp:538
#3 0x082ca889 in GFXVertexFormat::addElement (this=0x8c61c20, semantic=..., type=GFXDeclType_Float3, index=0) at ../../../../Engine/source/gfx/gfxVertexFormat.cpp:67
#4 0x082cb193 in _GFXVertexFormatConstructor<GFXVertexPC>::_construct (this=0x8c61c20) at ../../../../Engine/source/gfx/gfxVertexTypes.cpp:38
#5 0x0805ed1d in _GFXVertexFormatConstructor (this=0x8c61c20) at ../../../../Engine/source/gfx/gfxVertexFormat.h:200
#6 0x0805ed7f in getGFXVertexFormat<GFXVertexPC> () at ../../../../Engine/source/gfx/gfxVertexTypes.h:53
#7 0x0864ccd7 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at ../../../../Engine/source/lighting/advanced/advancedLightBinManager.cpp:50
#8 0x0864cf14 in global constructors keyed to _ZN23AdvancedLightBinManager13RIT_LightInfoE ()
at ../../../../Engine/source/lighting/advanced/advancedLightBinManager.cpp:817
#9 0x088cba75 in __do_global_ctors_aux ()
#10 0x0804bd04 in _init ()
#11 0x088cb999 in __libc_csu_init ()
#12 0xf7cd0af4 in __libc_start_main () from /lib32/libc.so.6
#13 0x0804cec1 in _start () at ../sysdeps/i386/elf/start.S:119
In this particular example it is using the vertex format definition strings before they are initialized.
I.e. a constructor calling
addElement( GFXSemantic::POSITION, GFXDeclType_Float3 );
before
const String GFXSemantic::POSITION = String( "POSITION" ).intern();
was initialized.
What I find curious is that neither the windows nor the OSX build are having these issues, I am only seeing them on the linux build ( gcc version 4.2.4 or 4.4.1, no difference ).
Has anyone ever encountered this before?
Here is an example backtrace, there are more, I resolved two but each time I resolve one I keep running into the next. Given that they do not exist in the other platform builds I am hoping for a simpler solution than to rewrite initialization code throughout the codebase.
Program received signal SIGSEGV, Segmentation fault.
0x08225114 in String::StringData::isInterned (this=0x0) at ../../../../Engine/source/core/util/str.cpp:374
374 return mIsInterned;
(gdb) bt
#0 0x08225114 in String::StringData::isInterned (this=0x0) at ../../../../Engine/source/core/util/str.cpp:374
#1 0x08221271 in String::isInterned (this=0x8c9abe0) at ../../../../Engine/source/core/util/str.cpp:604
#2 0x0822250a in String::intern (this=0x8c9abe0) at ../../../../Engine/source/core/util/str.cpp:538
#3 0x082ca889 in GFXVertexFormat::addElement (this=0x8c61c20, semantic=..., type=GFXDeclType_Float3, index=0) at ../../../../Engine/source/gfx/gfxVertexFormat.cpp:67
#4 0x082cb193 in _GFXVertexFormatConstructor<GFXVertexPC>::_construct (this=0x8c61c20) at ../../../../Engine/source/gfx/gfxVertexTypes.cpp:38
#5 0x0805ed1d in _GFXVertexFormatConstructor (this=0x8c61c20) at ../../../../Engine/source/gfx/gfxVertexFormat.h:200
#6 0x0805ed7f in getGFXVertexFormat<GFXVertexPC> () at ../../../../Engine/source/gfx/gfxVertexTypes.h:53
#7 0x0864ccd7 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at ../../../../Engine/source/lighting/advanced/advancedLightBinManager.cpp:50
#8 0x0864cf14 in global constructors keyed to _ZN23AdvancedLightBinManager13RIT_LightInfoE ()
at ../../../../Engine/source/lighting/advanced/advancedLightBinManager.cpp:817
#9 0x088cba75 in __do_global_ctors_aux ()
#10 0x0804bd04 in _init ()
#11 0x088cb999 in __libc_csu_init ()
#12 0xf7cd0af4 in __libc_start_main () from /lib32/libc.so.6
#13 0x0804cec1 in _start () at ../sysdeps/i386/elf/start.S:119
In this particular example it is using the vertex format definition strings before they are initialized.
I.e. a constructor calling
addElement( GFXSemantic::POSITION, GFXDeclType_Float3 );
before
const String GFXSemantic::POSITION = String( "POSITION" ).intern();
was initialized.
About the author
#2
All the client code is there. At this stage however my goal is not to get the client up and running and worry about OS graphics issues but rather operate in dedicated server mode.
02/19/2010 (2:12 pm)
It is not an attempt at separating server from client code. All the client code is there. At this stage however my goal is not to get the client up and running and worry about OS graphics issues but rather operate in dedicated server mode.
#3
02/19/2010 (2:36 pm)
Have you tried linking against STLport instead? Just a wild guess, since it's a string issue, and I've had similar in TGE. 
#4
Nope, it won't work with 1.0.1. The global ctor init code there is highly reliant on the linker sorting out correct object file and ctor ordering. The OSX and VC linkers manage, Linux ld apparently doesn't (which is okay as the C++ standard explicitly says the order is undefined).
Anyways, we overhauled this completely in 1.1 and have replaced reliance on global ctor ordering with a module system that computes init and shutdown ordering at runtime.
02/19/2010 (2:41 pm)
Nope, it won't work with 1.0.1. The global ctor init code there is highly reliant on the linker sorting out correct object file and ctor ordering. The OSX and VC linkers manage, Linux ld apparently doesn't (which is okay as the C++ standard explicitly says the order is undefined).
Anyways, we overhauled this completely in 1.1 and have replaced reliance on global ctor ordering with a module system that computes init and shutdown ordering at runtime.
#6
02/19/2010 (3:46 pm)
If you do get some results with the 1.1 release, I have a server that's screaming for attention :)
#7
If all goes well (no promises; especially not from me :), then 1.1 final (or some previous release) should have bank's Linux patches integrated so that Linux dedicated would compile and work out of the box. I worked with bank on this and we ironed out all these issues that Carsten has come across here and bank went on to make dedicated fully work.
02/19/2010 (3:54 pm)
If all goes well (no promises; especially not from me :), then 1.1 final (or some previous release) should have bank's Linux patches integrated so that Linux dedicated would compile and work out of the box. I worked with bank on this and we ironed out all these issues that Carsten has come across here and bank went on to make dedicated fully work.
#8
02/19/2010 (9:51 pm)
Ooh, nice. I can start looking at client issues then, maybe :) 
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
sure you started it correctly at all?