atexit problems on statics inside mixed assembly after moving to VS2005

[Aek]

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.
This occurs in static members / singletons (especially meyer type
singletons) which use locally declared static variables. These
variables are normally cleaned up automatically at shutdown of the
application by registering with the atexit. I break point the
destructor on a problem singleton class and notice that the destructor
of this static is called automatically *twice* with atexit. The second
call will cause the crash.

first automatic destruction (call stack):
ExecutableD.exe !GE::CShadowObj ects::~CShadowO bjects() Line 31 C++
ExecutableD.exe !`GE::CShadowOb jects::GetInsta nce'::`2'::`dyn amic
atexit destructor for 'g_ShadowObject s''() + 0xd bytes C++

second automatic destruction (call stack):
ExecutableD.exe !GE::CShadowObj ects::~CShadowO bjects() Line 31 C++
ExecutableD.exe !`GE::CShadowOb jects::GetInsta nce'::`2'::`dyn amic
atexit destructor for 'g_ShadowObject s''() + 0xd bytes C++

We notice that this singleton is implemented using a meyers singleton
that has a local static in the GetInstance() method and no specific
destroy call is needed. When I change the singleton to one that
contains a pointer to class and then call new in the GetInstance, then
it is fine. However I dont want to change tonnes of seemingly valid
code just to work around this crash.

We have no visible problems when we are running the application
outside of the IDE.

I believe it is a similar problem to this one described here:
http://groups.google.com.au/group/mi...5&rnum=3&hl=en

I think that perhaps it has something to do with the mix managed /
unmanaged code or perhaps it has something to do with using /
clr:oldSyntax and Managed Extensions for C++.

This page ( http://msdn2.microsoft.com/en-us/lib...68(VS.80).aspx
) suggests that the /clr option will provide support for "static
initialization of C++ variables in mixed images". Is this also true
then for /clr:oldSyntax ?

We have a number of native C++ libs (no clr) that are then linked into
an executable project built with /clr:oldSyntax. The executable
project contains Managed Extension C++ (hence the need for the
oldSyntax flag)
Ideally we will eventually get rid of Managed Extensions for C++ and
port to C++/CLI.
My main question is:
Could use of oldSyntax and Managed Extensions be a cause of the atexit
problems with static variables in a mixed assembly?

Any other suggestions?

Thankyou for your time
Josh

[Carl Daniel [VC++ MVP]]

Aek wrote:

My main question is:
Could use of oldSyntax and Managed Extensions be a cause of the atexit
problems with static variables in a mixed assembly?

It could be. Shouldn't be, but it's definitely the case that /clr was
tested a lot more carefully than /clr:oldSyntax for VS2005.

>
Any other suggestions?

Contact PSS. It sounds like you're looking at something complex and subtle
that may require inside knowledge to fully diagnose and understand.

-cd

[Ben Voigt [C++ MVP]]

"Aek" <ae*********@gm ail.comwrote in message
news:11******** **************@ x35g2000prf.goo glegroups.com.. .

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.
This occurs in static members / singletons (especially meyer type
singletons) which use locally declared static variables. These
variables are normally cleaned up automatically at shutdown of the
application by registering with the atexit. I break point the

Are you doing the atexit registration in code, or the compiler is doing it
automatically?

destructor on a problem singleton class and notice that the destructor
of this static is called automatically *twice* with atexit. The second
call will cause the crash.

first automatic destruction (call stack):
ExecutableD.exe !GE::CShadowObj ects::~CShadowO bjects() Line 31 C++
ExecutableD.exe !`GE::CShadowOb jects::GetInsta nce'::`2'::`dyn amic
atexit destructor for 'g_ShadowObject s''() + 0xd bytes C++

second automatic destruction (call stack):
ExecutableD.exe !GE::CShadowObj ects::~CShadowO bjects() Line 31 C++
ExecutableD.exe !`GE::CShadowOb jects::GetInsta nce'::`2'::`dyn amic
atexit destructor for 'g_ShadowObject s''() + 0xd bytes C++

We notice that this singleton is implemented using a meyers singleton
that has a local static in the GetInstance() method and no specific
destroy call is needed. When I change the singleton to one that
contains a pointer to class and then call new in the GetInstance, then
it is fine. However I dont want to change tonnes of seemingly valid
code just to work around this crash.

We have no visible problems when we are running the application
outside of the IDE.

I believe it is a similar problem to this one described here:
http://groups.google.com.au/group/mi...5&rnum=3&hl=en

I think that perhaps it has something to do with the mix managed /
unmanaged code or perhaps it has something to do with using /
clr:oldSyntax and Managed Extensions for C++.

This page ( http://msdn2.microsoft.com/en-us/lib...68(VS.80).aspx
) suggests that the /clr option will provide support for "static
initialization of C++ variables in mixed images". Is this also true
then for /clr:oldSyntax ?

We have a number of native C++ libs (no clr) that are then linked into
an executable project built with /clr:oldSyntax. The executable
project contains Managed Extension C++ (hence the need for the
oldSyntax flag)
Ideally we will eventually get rid of Managed Extensions for C++ and
port to C++/CLI.
My main question is:
Could use of oldSyntax and Managed Extensions be a cause of the atexit
problems with static variables in a mixed assembly?

Any other suggestions?

Thankyou for your time
Josh

[Aek]

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

"Aek" <aek.muld...@gm ail.comwrote in message

news:11******** **************@ x35g2000prf.goo glegroups.com.. .

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The compiler is generating the atexit registration automatically.

Thanks
Josh

[Ben Voigt [C++ MVP]]

"Aek" <ae*********@gm ail.comwrote in message
news:11******** **************@ j4g2000prf.goog legroups.com...

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

>"Aek" <aek.muld...@gm ail.comwrote in message

news:11******* *************** @x35g2000prf.go oglegroups.com. ..

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The compiler is generating the atexit registration automatically.

Can you place a breakpoint on atexit and see if the cleanup code is
registered twice?

Are there multiple static objects in the same function, of which it would be
possible that only some are fully constructed due to exceptions?

>
Thanks
Josh

[Aek]

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

"Aek" <aek.muld...@gm ail.comwrote in message

news:11******** **************@ x35g2000prf.goo glegroups.com.. .

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The atexit registration is automatically generated by the compiler.
After some experimenting yesterday, I found that if I rebuild one of
my problematic native C++ libs with the /clr:oldSyntax flag then the
problems with the statics in that lib are resolved. Problem is though
that one of the native libs is a graphics engine and it goes from real
time to slower than powerpoint with /clr enabled in the lib, so I
would like to leave the native C++ libs without clr.

Thankyou
Josh

[Aek]

On Jun 22, 10:44 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

"Aek" <aek.muld...@gm ail.comwrote in message

news:11******** **************@ j4g2000prf.goog legroups.com...

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

"Aek" <aek.muld...@gm ail.comwrote in message

>news:11******* *************** @x35g2000prf.go oglegroups.com. ..

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The compiler is generating the atexit registration automatically.

Can you place a breakpoint on atexit and see if the cleanup code is
registered twice?

Yes I can, I just need to find where it is. Ill give it a go today.

Are there multiple static objects in the same function, of which it would be
possible that only some are fully constructed due to exceptions?

No, generally the problem is seen in functions that only have a single
static in the function. There seems to be the same problem with all
locally declared statics in native C++ libs (not just 1 case), so I do
not believe exceptions are occuring causing only some statics to be
fully constructed.

Thanks for your help so far.
Josh

[Ben Voigt [C++ MVP]]

"Aek" <ae*********@gm ail.comwrote in message
news:11******** **************@ e9g2000prf.goog legroups.com...

On Jun 22, 10:44 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

>"Aek" <aek.muld...@gm ail.comwrote in message

news:11******* *************** @j4g2000prf.goo glegroups.com.. .

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:
"Aek" <aek.muld...@gm ail.comwrote in message

>>news:11****** *************** *@x35g2000prf.g ooglegroups.com ...

We recently moved our large codebase over from VS7 to 8 and found
that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The compiler is generating the atexit registration automatically.

Can you place a breakpoint on atexit and see if the cleanup code is
registered twice?

Yes I can, I just need to find where it is. Ill give it a go today.

>Are there multiple static objects in the same function, of which it would
be
possible that only some are fully constructed due to exceptions?

No, generally the problem is seen in functions that only have a single
static in the function. There seems to be the same problem with all
locally declared statics in native C++ libs (not just 1 case), so I do
not believe exceptions are occuring causing only some statics to be
fully constructed.

Ok, that was the only reason I could think of for having more than one
cleanup handler executed for the same function.

Oh... is there any possibility that the singleton is accessed from other
atexit handlers/static destructors?

>
Thanks for your help so far.
Josh

[Ben Voigt [C++ MVP]]

"Aek" <ae*********@gm ail.comwrote in message
news:11******** *************@i 38g2000prf.goog legroups.com...

On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

>"Aek" <aek.muld...@gm ail.comwrote in message

news:11******* *************** @x35g2000prf.go oglegroups.com. ..

We recently moved our large codebase over from VS7 to 8 and found that
we now get access violations in atexit calls at shutdown when
debugging the application in VS2005.

The atexit registration is automatically generated by the compiler.
After some experimenting yesterday, I found that if I rebuild one of
my problematic native C++ libs with the /clr:oldSyntax flag then the
problems with the statics in that lib are resolved. Problem is though
that one of the native libs is a graphics engine and it goes from real
time to slower than powerpoint with /clr enabled in the lib, so I
would like to leave the native C++ libs without clr.

Can you open your assembly with .NET Reflector and make sure that the
SuppressUnmanag edCodeSecurityA ttribute is applied?

>
Thankyou
Josh

[Aek]

On Jun 22, 10:44 am, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

Can you place a breakpoint on atexit and see if the cleanup code is
registered twice?

I stepped through the local static creation and can confirm that the
atexit code for the local static is _not_ being called twice, but the
destructor is called twice on the same object.

-Josh