bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ltdl bugs


From: Jeff Squyres
Subject: Re: ltdl bugs
Date: Sun, 3 Apr 2005 14:13:00 -0400

On Apr 3, 2005, at 11:33 AM, Ralf Wildenhues wrote:

[snipped much explanation]
I'll try to rephrase:  You may actually do what you intend in
lt_dlexit(), because that is (like MPI_Finalize) final in the sense,
that after as many lt_dlexit's as lt_dlinit's we may completely shut
down our stuff and free every data we own.

Ah.  That would be perfect.

You're right that in my case, I don't care if the memory is freed in lt_dlclose() -- I only care at the end of time (i.e., after lt_dlexit()).

You may _not_ do this in lt_dlclose(), however, because the user may
issue another lt_dlopen() of the very same module (which may be NULL, or
"foo.la" made resident), which in fact is already open.

Combine that with the fact that I simply don't know what will happen
then for any of the system-specific module interfaces we implement.
Thus, I regard this as disallowed.

That works. I'll go mull on this and try to come up with another patch (for lt_dlexit() this time). May take a few days; I had a window of opportunity this morning. :-)

However, you mentioned something a mail or two ago:

Maybe we should explicitly add to the docs: "If another part of your application uses a module loading interface (such as dlopen()) without wrapping it through libltdl, then the behavior is undefined."

You probably want to add this regardless of the what happens with a patch to fix this memory leak or not. We take very much the same approach in my MPI implementations: if you go outside the library's interface and potentially mess with any of the data or communication channels that the library is using, you do so at your own risk.

--
{+} Jeff Squyres
{+} address@hidden
{+} http://www.lam-mpi.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]