freeing static managed objects from native dll - cant use dllmain

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a managed cpp wrapper. Im using this in a native dll as a static
variable. I need to free this library when the dll is done being used. The
perfect place to do this is DllMain for DLL_PROCESS_DETACH, but I can't do
this when touching managed code, even if its just calling "delete
someObject;". Any recommendations on how to free this object (it needs to be
freed when the dll is being unloaded from its caller). Since the CRT is
already spun up, I would imagine freeing an object in DllMain should be no
problem (a loader lock issue won't be a problem here.. correct?). If thats so
and this is the best way, is there a way to avoid the loader lock msgbox that
comes up? (this would be the 'Managed Debugging Assistant 'LoaderLock' has
detected a problem in...' dialog'
Thanks!
 
Hi Adam,
I have a managed cpp wrapper. Im using this in a native dll as
a static variable. I need to free this library when the dll is done
being used. The perfect place to do this is DllMain for
DLL_PROCESS_DETACH, but I can't do this when touching
managed code, even if its just calling "delete someObject;".
Click to expand...

I am not very clear about how do you freeing static managed objects in that
native dll, but since you are programming with the new C++/CLI environment,
how about using the new auto_gcroot class which could take the resource
management automatically, then I think you needn't to worry about the
GCHandle clean-up stuff...

Please refer to the following links for the related doc and samples:

auto_gcroot Class
http://msdn2.microsoft.com/en-us/library/ms177048

Mixing Native and Managed Types in C++
http://weblogs.asp.net/kennykerr/archive/2005/07/12/419102.aspx

A rational attempt to substantiate C++/CLI as a first class CLI language
http://www.codeproject.com/managedcpp/whycppcli.asp?df=100&forumid=201953&ex
p=0&select=1184146


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the response. Im still not sure how this stops the loader lock
issue.
This object still needs to be created and deleted at some point. The example
on Ken Kerr's site, the destructor is called automatically from code the
compiler inserts. Since this object is created dynamically, and isn't created
on the stack the destructor would have to be called automatically, no? If I
include
static auto_gcroot<SomeType^> globally inside of a dll, won't that still get
initialized when the library is loaded and DLLMain is invoked (at what point
do static objects get created?) and then hit the loader lock issue?



"Gary Chang[MSFT]" said:
Hi Adam,
I have a managed cpp wrapper. Im using this in a native dll as
a static variable. I need to free this library when the dll is done
being used. The perfect place to do this is DllMain for
DLL_PROCESS_DETACH, but I can't do this when touching
managed code, even if its just calling "delete someObject;".
Click to expand...

I am not very clear about how do you freeing static managed objects in that
native dll, but since you are programming with the new C++/CLI environment,
how about using the new auto_gcroot class which could take the resource
management automatically, then I think you needn't to worry about the
GCHandle clean-up stuff...

Please refer to the following links for the related doc and samples:

auto_gcroot Class
http://msdn2.microsoft.com/en-us/library/ms177048

Mixing Native and Managed Types in C++
http://weblogs.asp.net/kennykerr/archive/2005/07/12/419102.aspx

A rational attempt to substantiate C++/CLI as a first class CLI language
http://www.codeproject.com/managedcpp/whycppcli.asp?df=100&forumid=201953&ex
p=0&select=1184146


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Hi Adam,
Since this object is created dynamically, and isn't created on
the stack the destructor would have to be called automatically,
no? If I include static auto_gcroot<SomeType^> globally inside
of a dll, static auto_gcroot<SomeType^> globally inside of a dll,
won't that still get initialized when the library is loaded and
DLLMain is invoked (at what point do static objects get created?)
and then hit the loader lock issue?
Click to expand...

A local static object is initialized when execution first reaches its
declaration. so it will be initialized before the DLLMain if you define it
global in your DLL code.

And the static objects are destroyed in the reverse order of their
construction, when the main routine returns or when the application exits,
then the program terminates. so the static objects will be destroyed after
the DLL_PROCESS_DETACH.

If the loader lock issue still exists with the auto_gcroot<SomeType^>, I
suggest you may take another approach in this case, such as using the IJW
to interop the managed objects, you may take a look on the following
article for reference:

Using managed code in an unmanaged application
http://www.codeproject.com/managedcpp/ijw_unmanaged.asp


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Gary,
I think the problem at hand isn't being understood.
Using any of these techniques IJW, auto_gcroot, etc still doesn't touch upon
the root cause and resolution here. Its specifically stated in ms docs not to
use the managed objects statically initialized in the lib because the same
loader lock issue applies. Im finding it hard to believe that after a week of
searching and hours and hours of testing I can't seem to get an answer let
alone from MS on this. I get plenty of responses and information on how to
avoid the loader lock issue upon loading objects, but no one seems to know
how to properly destroy these objects.
Theres an article that recommends having the caller call methods on the dll
to load/unload your resources but when you can't control the caller and have
only a DLLMain handy, no one seems to know what to do. Can anyone provide
some information on this, possibly from the VC Team if checking this list?
Thanks!
Adam


"Gary Chang[MSFT]" said:
Hi Adam,
Since this object is created dynamically, and isn't created on
the stack the destructor would have to be called automatically,
no? If I include static auto_gcroot<SomeType^> globally inside
of a dll, static auto_gcroot<SomeType^> globally inside of a dll,
won't that still get initialized when the library is loaded and
DLLMain is invoked (at what point do static objects get created?)
and then hit the loader lock issue?
Click to expand...

A local static object is initialized when execution first reaches its
declaration. so it will be initialized before the DLLMain if you define it
global in your DLL code.

And the static objects are destroyed in the reverse order of their
construction, when the main routine returns or when the application exits,
then the program terminates. so the static objects will be destroyed after
the DLL_PROCESS_DETACH.

If the loader lock issue still exists with the auto_gcroot<SomeType^>, I
suggest you may take another approach in this case, such as using the IJW
to interop the managed objects, you may take a look on the following
article for reference:

Using managed code in an unmanaged application
http://www.codeproject.com/managedcpp/ijw_unmanaged.asp


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Btw... I followed your advice and posted last week in:
Visual C++ Language
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=96
I was onto a good start with Jonathan Caves from the VC team, but he stopped
responding to the thread when I asked the same question. Doh! If you happen
to be best friends with him, something tells me he would have the solution
here : )
Thanks!




"Gary Chang[MSFT]" said:
Hi Adam,
Since this object is created dynamically, and isn't created on
the stack the destructor would have to be called automatically,
no? If I include static auto_gcroot<SomeType^> globally inside
of a dll, static auto_gcroot<SomeType^> globally inside of a dll,
won't that still get initialized when the library is loaded and
DLLMain is invoked (at what point do static objects get created?)
and then hit the loader lock issue?
Click to expand...

A local static object is initialized when execution first reaches its
declaration. so it will be initialized before the DLLMain if you define it
global in your DLL code.

And the static objects are destroyed in the reverse order of their
construction, when the main routine returns or when the application exits,
then the program terminates. so the static objects will be destroyed after
the DLL_PROCESS_DETACH.

If the loader lock issue still exists with the auto_gcroot<SomeType^>, I
suggest you may take another approach in this case, such as using the IJW
to interop the managed objects, you may take a look on the following
article for reference:

Using managed code in an unmanaged application
http://www.codeproject.com/managedcpp/ijw_unmanaged.asp


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
I was onto a good start with Jonathan Caves from the
VC team, but he stopped responding to the thread when
I asked the same question.
...
Click to expand...

yes, Adam, I have already found your post in the MSDN forum and contacted
Jonathan a few days ago, I have also consulted this issue with our
corresponding VC++ team members via email, but I did not receive response.
It appears this is somehow a new scenario and we don't have much experience
with it.

So in this scenario, if you confirm there is GCHandle leak problem with
your current approach, I think the most efficient way for you to resolve it
to contact our PSS support engineers to help you on this issue. This may
need you submit a support incident in Microsoft PSS (Product Support
Service). As a MSDN subscriber, you have two free support incidents.

By the way, if the problem is confirmed by Microsoft PSS as a product
issue, PSS won't charge money. Every MSDN subscriber has two free support
incidents. You could use one of them to contact Microsoft PSS. So you don't
need to pay money yet. Surely if the issue is a product issue, you still
have two free support incidents.

For your reference, I attached steps to contact Microsoft PSS here: You can
contact Microsoft Product Support directly to discuss additional support
options you may have available, by contacting us at 1-(800)936-5800 or by
choosing one of the options listed at
http://support.microsoft.com/common/international.aspx?rdpath=gp;en-us;offer
prophone

If there is anything unclear, please feel free to post here. We are glad to
be of assistance.


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top