移动到VS2005后混合装配中的静力学问题 [英] atexit problems on statics inside mixed assembly after moving to VS2005
问题描述
我们最近将我们的大型代码库从VS7移到了8，并且发现
我们现在在关机时的atexit调用中获得访问冲突时
在VS2005中调试应用程序。
这发生在使用本地声明的静态变量的静态成员/单例（尤其是meyer类型
单例）中。这些
变量通常在关闭
应用程序时通过注册atexit自动清理。我在一个问题单例类中断点
析构函数，并注意到这个静态的析构函数
被自动调用*两次*和atexit。第二次
调用将导致崩溃。
首次自动销毁（调用堆栈）：
ExecutableD.exe！GE： ：CShadowObjects :: ~CShadowObject s（）第31行C ++
ExecutableD.exe！`GE :: CShadowObjects :: GetInstance''::`2''::`dynamic
atexit析构函数''g_ShadowObjects''''（）+ 0xd bytes C ++
秒自动销毁（调用堆栈）：
ExecutableD.exe！ GE :: CShadowObjects :: ~CShadowObject s（）第31行C ++
ExecutableD.exe！`GE :: CShadowObjects :: GetInstance''::`2''::`dynamic
atexit析构函数''g_ShadowObjects'''''（+）+ 0xd字节C ++
我们注意到这个单例是使用meyers singleton实现的
在GetInstance（）方法中有一个本地静态，并且不需要特定的
destroy调用。当我将单例更改为一个
包含指向class的指针然后在GetInstance中调用new时，那么
就可以了。但是，我不想改变吨看似有效的
代码只是为了解决这次崩溃。
我们在运行应用程序时没有明显的问题<在IDE之外的
。
我认为这与此处描述的类似问题：
http://groups.google.com.au/group/mi...5&rnum=3&hl=en
我认为也许它与mix managed /
非托管代码有关，或者它与使用/
clr有关：用于C ++的oldSyntax和Managed Extensions。
此页面（ http://msdn2.microsoft.com/en-us/lib...68(VS.80 ）.aspx
）建议/ clr选项将支持静态
混合图像中C ++变量的初始化。这也是真的
那么对于/ clr：oldSyntax？
我们有许多原生的C ++库（没有clr）然后被链接到
使用/ clr：oldSyntax构建的可执行项目。可执行的
项目包含托管扩展C ++（因此需要
oldSyntax标志）
理想情况下，我们最终将摆脱Managed Extensions for C ++和
到C ++ / CLI的端口。
我的主要问题是：
使用oldSyntax和Managed Extensions是导致atexit的原因
混合装配中静态变量的问题？
还有其他建议吗？
谢谢您的时间
Josh
Aek写道：
我的主要问题是：
使用oldSyntax和Managed Extensions可能导致混合程序集中静态变量出现atexit
问题？
可能是。不应该，但是肯定的情况是/ clr比/ clr：oldSyntax for VS2005更仔细地测试了b $ b。
>
还有其他建议吗？
联系PSS。听起来你正在寻找一些复杂而微妙的东西，可能需要内部知识才能完全诊断和理解。
-cd
" Aek" < ae ********* @ gmail.comwrote in message
news：11 ********************* *@x35g2000prf.googlegr oups.com ...
我们最近将我们的大型代码库从VS7移到了8，发现
我们
在VS2005中调试应用程序时，现在在atexit调用中获取访问冲突。
这发生在静态成员/单例中（尤其是meyer类型
单例）使用本地声明的静态变量。这些
变量通常在关闭
应用程序时通过注册atexit自动清理。我突破了
你是在代码中进行atexit注册，还是编译器自动执行它是什么？
自动？
< blockquote class =post_quotes>
问题单例类的析构函数，并注意析构函数
的这个静态是用atexit自动调用*两次*。第二次
调用将导致崩溃。
首次自动销毁（调用堆栈）：
ExecutableD.exe！GE： ：CShadowObjects :: ~CShadowObject s（）第31行C ++
ExecutableD.exe！`GE :: CShadowObjects :: GetInstance''::`2''::`dynamic
atexit析构函数''g_ShadowObjects''''（）+ 0xd bytes C ++
秒自动销毁（调用堆栈）：
ExecutableD.exe！ GE :: CShadowObjects :: ~CShadowObject s（）第31行C ++
ExecutableD.exe！`GE :: CShadowObjects :: GetInstance''::`2''::`dynamic
atexit析构函数''g_ShadowObjects'''''（+）+ 0xd字节C ++
我们注意到这个单例是使用meyers singleton实现的
在GetInstance（）方法中有一个本地静态，并且不需要特定的
destroy调用。当我将单例更改为一个
包含指向class的指针然后在GetInstance中调用new时，那么
就可以了。但是，我不想改变吨看似有效的
代码只是为了解决这次崩溃。
我们在运行应用程序时没有明显的问题<在IDE之外的
。
我认为这与此处描述的类似问题：
http://groups.google.com.au/group/mi...5&rnum=3&hl=en
我认为也许它与mix managed /
非托管代码有关，或者它与使用/
clr有关：用于C ++的oldSyntax和Managed Extensions。
此页面（ http://msdn2.microsoft.com/en-us/lib...68(VS.80).as px
混合图像中C ++变量的初始化。这也是真的
那么对于/ clr：oldSyntax？
我们有许多原生的C ++库（没有clr）然后被链接到
使用/ clr：oldSyntax构建的可执行项目。可执行的
项目包含托管扩展C ++（因此需要
oldSyntax标志）
理想情况下，我们最终将摆脱Managed Extensions for C ++和
到C ++ / CLI的端口。
我的主要问题是：
使用oldSyntax和Managed Extensions是导致atexit的原因
混合装配中静态变量的问题？
还有其他建议吗？
谢谢您的时间
Josh
6月22日凌晨1点27分，Ben Voigt [C ++ MVP]" < r ... @nospam.nospamwrote：
" Aek" < aek.muld ... @ gmail.com写信息
新闻：11 ********************* *@x35g2000prf.googlegr oups.com ...
我们最近将我们的大型代码库从VS7移到了8，发现
我们现在在关机时调用atexit中的访问权限，这是在VS2005中调试应用程序的
。
编译器自动生成atexit注册。
谢谢
Josh
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::CShadowObjects::~CShadowObject s() Line 31 C++
ExecutableD.exe!`GE::CShadowObjects::GetInstance'': :`2''::`dynamic
atexit destructor for ''g_ShadowObjects''''() + 0xd bytes C++
second automatic destruction (call stack):
ExecutableD.exe!GE::CShadowObjects::~CShadowObject s() Line 31 C++
ExecutableD.exe!`GE::CShadowObjects::GetInstance'': :`2''::`dynamic
atexit destructor for ''g_ShadowObjects''''() + 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 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
"Aek" <ae*********@gmail.comwrote in message
news:11**********************@x35g2000prf.googlegr oups.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 theAre 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::CShadowObjects::~CShadowObject s() Line 31 C++
ExecutableD.exe!`GE::CShadowObjects::GetInstance'': :`2''::`dynamic
atexit destructor for ''g_ShadowObjects''''() + 0xd bytes C++
second automatic destruction (call stack):
ExecutableD.exe!GE::CShadowObjects::~CShadowObject s() Line 31 C++
ExecutableD.exe!`GE::CShadowObjects::GetInstance'': :`2''::`dynamic
atexit destructor for ''g_ShadowObjects''''() + 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
On Jun 22, 1:27 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:"Aek" <aek.muld...@gmail.comwrote in message
news:11**********************@x35g2000prf.googlegr oups.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
这篇关于移动到VS2005后混合装配中的静力学问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
