std::cout and static initialisation order

[clilley]

The following code causes a segmentation fault on DEC Tru64:

foo.cc (built into libFoo.so)
//---------------------------
include <iostream>

bool createFoo()
{
std::cout << "createFoo" << std::endl;
}

bool registerCreate = createFoo();
//-----------------------------------------

main.cc (built into a.out and linked to libFoo.so)
//-----------------------------
int main (int argc, char *argv[])
{
// Do nothing
};
//------------------------------------------

What is happening is that at runtime the library loader is loading the
libFoo.so library and attempting to initialise any
statics present in libFoo.so. This causes an attempt to initialise the bool
registerCreate variable in foo.cc, by calling the createFoo
method. The SEGV occurs because std::cout has not yet been initialised.

The same code works fine using gnu g++ 3.3.1

So my question is, is this a bug or is this behaviour allowed under the C++
standard?

I realise that the order of static initialisation, before main is entered,
is undeterministic, but I would have expected the runtime system to be
initialised before the user defined librarys are loaded.

Any help would be gratefully appreciated.

Regards

Clive Lilley.

[Victor Bazarov]

clilley wrote:

The following code causes a segmentation fault on DEC Tru64:

foo.cc (built into libFoo.so)
//---------------------------
include <iostream>

bool createFoo()
{
std::cout << "createFoo" << std::endl;
}

bool registerCreate = createFoo();
//-----------------------------------------

main.cc (built into a.out and linked to libFoo.so)
//-----------------------------
int main (int argc, char *argv[])
{
// Do nothing
};
//------------------------------------------

What is happening is that at runtime the library loader is loading the
libFoo.so library and attempting to initialise any
statics present in libFoo.so. This causes an attempt to initialise the bool
registerCreate variable in foo.cc, by calling the createFoo
method. The SEGV occurs because std::cout has not yet been initialised.

The same code works fine using gnu g++ 3.3.1

So my question is, is this a bug or is this behaviour allowed under the C++
standard?
It is an apparent bug because the C++ Standard requires that 'cout' be
initialised _before_ any user code can be executed, initialisation of
static objects included.
I realise that the order of static initialisation, before main is entered,
is undeterministic, but I would have expected the runtime system to be
initialised before the user defined librarys are loaded.

You're correct in your expectations.

V

[clilley]

Thanks for confirming my thoughts. Do you now the relevent section in the
C++ standard that confirms your statement. It would be nice to point my boss
to the relevent detail.

regards

Clive Lilley

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:K1****************@newsread1.dllstx09.us.to.v erio.net...

clilley wrote:

The following code causes a segmentation fault on DEC Tru64:

foo.cc (built into libFoo.so)
//---------------------------
include <iostream>

bool createFoo()
{
std::cout << "createFoo" << std::endl;
}

bool registerCreate = createFoo();
//-----------------------------------------

main.cc (built into a.out and linked to libFoo.so)
//-----------------------------
int main (int argc, char *argv[])
{
// Do nothing
};
//------------------------------------------

What is happening is that at runtime the library loader is loading the
libFoo.so library and attempting to initialise any
statics present in libFoo.so. This causes an attempt to initialise the
bool registerCreate variable in foo.cc, by calling the createFoo
method. The SEGV occurs because std::cout has not yet been initialised.

The same code works fine using gnu g++ 3.3.1

So my question is, is this a bug or is this behaviour allowed under the
C++ standard?

It is an apparent bug because the C++ Standard requires that 'cout' be
initialised _before_ any user code can be executed, initialisation of
static objects included.

I realise that the order of static initialisation, before main is
entered, is undeterministic, but I would have expected the runtime system
to be initialised before the user defined librarys are loaded.

You're correct in your expectations.

V

[Victor Bazarov]

clilley wrote:

Thanks for confirming my thoughts. Do you now the relevent section in the
C++ standard that confirms your statement. It would be nice to point my boss
to the relevent detail.
Please don't top-post. Thanks.

Regarding the issue at hand, I may have been a bit hasty. Upon close
examination of the relevant part of the Standard (27.3) it looks that
the initialisation of 'cout' and the like is only required to happen
before an object of class "basic_ios<charT,traits>::Init" is constucted
and before the body of 'main' begins execution. IOW, the 'std::cout'
object is not necessarily there when static objects are constructed.

To overcome this, you could make sure that 'std::cout' is there by
declaring an object of type 'std::basic_ios<charT,traits>::Init":

bool createFoo()
{
std::basic_ios<char>::Init dummy;
std::cout << "createFoo" << std::endl;
}

V

regards

Clive Lilley

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:K1****************@newsread1.dllstx09.us.to.v erio.net...

clilley wrote:

The following code causes a segmentation fault on DEC Tru64:

foo.cc (built into libFoo.so)
//---------------------------
include <iostream>

bool createFoo()
{
std::cout << "createFoo" << std::endl;
}

bool registerCreate = createFoo();
//-----------------------------------------

main.cc (built into a.out and linked to libFoo.so)
//-----------------------------
int main (int argc, char *argv[])
{
// Do nothing
};
//------------------------------------------

What is happening is that at runtime the library loader is loading the
libFoo.so library and attempting to initialise any
statics present in libFoo.so. This causes an attempt to initialise the
bool registerCreate variable in foo.cc, by calling the createFoo
method. The SEGV occurs because std::cout has not yet been initialised.

The same code works fine using gnu g++ 3.3.1

So my question is, is this a bug or is this behaviour allowed under the
C++ standard?

It is an apparent bug because the C++ Standard requires that 'cout' be
initialised _before_ any user code can be executed, initialisation of
static objects included.

I realise that the order of static initialisation, before main is
entered, is undeterministic, but I would have expected the runtime system
to be initialised before the user defined librarys are loaded.

You're correct in your expectations.

V

V

[Howard Hinnant]

In article <MO*****************@newsread1.dllstx09.us.to.veri o.net>,
Victor Bazarov <v.********@comAcast.net> wrote:

clilley wrote:

Thanks for confirming my thoughts. Do you now the relevent section in the
C++ standard that confirms your statement. It would be nice to point my
boss
to the relevent detail.

Please don't top-post. Thanks.

Regarding the issue at hand, I may have been a bit hasty. Upon close
examination of the relevant part of the Standard (27.3) it looks that
the initialisation of 'cout' and the like is only required to happen
before an object of class "basic_ios<charT,traits>::Init" is constucted
and before the body of 'main' begins execution. IOW, the 'std::cout'
object is not necessarily there when static objects are constructed.

To overcome this, you could make sure that 'std::cout' is there by
declaring an object of type 'std::basic_ios<charT,traits>::Init":

bool createFoo()
{
std::basic_ios<char>::Init dummy;
std::cout << "createFoo" << std::endl;
}

There is an open defect report on this one:

http://www.open-std.org/jtc1/sc22/wg...ctive.html#369

The issue was discussed just last month at the Redmond meeting. We
agree the standard is in error, and the intent is to guarantee that if
<iostream> is included prior to a use in a translation unit, then things
will work fine, even in static constructors and destructors. The
solution proposed by Victor should also be guaranteed to work.

-Howard

[Pete Becker]

Victor Bazarov wrote:

But the linker gives the following errors. There is some conflict with the
lib msvcprt.lib
************************************
[...]
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other
libs; us
e /NODEFAULTLIB:library

Can you see the suggestion in this message?

Agreed, he should definitely go to a VC newsgroup. Just to clarify,
though, I have never yet seen a situation in which the linker's
suggested /NODEFAULTLIB is the right answer. Figure out where the
conflict is coming from and fix the problem. In this case some .obj
files were compiled to use the static runtime, and some to use the
dynamic. They don't mix.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Pete Becker wrote:

Victor Bazarov wrote:

But the linker gives the following errors. There is some conflict with the
lib msvcprt.lib
************************************
[...]
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other
libs; us
e /NODEFAULTLIB:library

Can you see the suggestion in this message?

Agreed, he should definitely go to a VC newsgroup. Just to clarify,
though, I have never yet seen a situation in which the linker's
suggested /NODEFAULTLIB is the right answer. Figure out where the
conflict is coming from and fix the problem. In this case some .obj
files were compiled to use the static runtime, and some to use the
dynamic. They don't mix.

Sorry, wrong thread. :-{

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)