Out-of-order Dll Teardown

[Danilo Almeida]

FreeLibrary() will not ignore dependencies.  That would be a bug.

You do not need the cleanup function if there is no state that needs to be
cleaned up on tear-down.  On the other hand, having the cleanup function now
allows you to add such state later w/o affecting the interface between the
app and the DLL.

- Danilo

-----Original Message-----
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
Ben Creech
Sent: Wednesday, January 29, 2003 8:27 PM
To: krbdev at MIT.EDU

Thanks, I hadn't noticed that part of the docs.  Now, I wonder if
FreeLibrary will also ignore the dependencies.  If so, I'm not sure how
I'll ever be able to tell for sure whether krb5_32.dll is still alive
before trying to free things.  I'll try a few things (such as
GetModuleHandle) tomorrow.

On the other hand, exporting a cleanup function is looking less ugly now
that I think about it.

On Wed, 2003-01-29 at 22:45, Danilo Almeida wrote:
> Ben,
> 
> Your logic is correct.  Option [1] is appropriate if and only if you know
> the process is being torn down.
> 
> From MSDN docs for DllMain:
> 
> ---
> lpvReserved
> 
> If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads
> and non-NULL for static loads.
> 
> If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if DllMain has
been
> called by using FreeLibrary and non-NULL if DllMain has been called during
> process termination.
> ---
> 
> Therefore, if reason is DLL_PROCESS_DETACH and reserved is non-NULL, B.dll
> can punt freeing up the context, etc.  If you have any persistent state
that
> needs to be cleaned up (i.e., you need to destroy tickets*), then you
still
> need to have some kind of cleanup routine in B.dll that gets called before
> the app exists.
> 
> - Danilo
> 
> -----Original Message-----
> From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf Of
> Ben Creech
> Sent: Wednesday, January 29, 2003 7:04 PM
> To: krbdev at MIT.EDU
> 
> This question isn't exactly Kerberos-specific, but it is still pertinent
> to this list.  In summary, I'm getting odd behavior from Windows on
> teardown of KfW's krb5_32.dll.
> 
> As noted in athena\auth\krbcc\src\dll\cacheapi.cxx, Windows doesn't
> follow the Dll dependency tree when tearing down Dlls with calls to
> DllMain with DLL_PROCESS_DETACH.  For example, if A.exe loads B.dll
> which in turn loads C.dll, Windows apparently sometimes tears down C.dll
> before B.dll (A->C->B instead of A->B->C).
> 
> I say "apparently" because I have observed this in my own program. 
> A.exe loads B.dll which delay-loads krb5_32.dll.  B.dll calls
> krb5_init_context.  Things Happen.  A.exe exits.  Windows tears down
> krb5_32.dll, which shuts down the ccache connection and frees its heap
> (via the run-time library).  At this point, B.dll's DllMain is finally
> called.  As part of the cleanup routine, B.dll calls krb5_free_context. 
> Whoops, that's no longer a valid pointer!  Program crashes.
> 
> Of course, I can simply comment out my krb5_free_context since the
> process is exiting anyway [1].  Alternately, I can make A.exe call a
> cleanup function before it exits [2].
> 
> Incidentally, I didn't get this behavior until I started using debug
> dlls from 2.2-beta-2; the downloadable 2.1 release build didn't do it. 
> After poking through the code, I'm fairly satisfied that 2.2 added
> nothing that would cause my problem, so it's probably the fact that I'm
> using debug binaries now.
> 
> Can anyone tell me if my logic is correct?  I'm worried that I'm either
> doing something wrong on my side, or there is a subtle bug in 2.2 beta 2
> (is anyone testing it with delay-loading)?
> 
> Thanks,
> Ben Creech
> NCSU ITECS
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev