Re: dlclose changed behavior in 10.5.7
Re: dlclose changed behavior in 10.5.7
- Subject: Re: dlclose changed behavior in 10.5.7
- From: Shai Shasag <email@hidden>
- Date: Sun, 31 May 2009 10:06:00 +0300
Hi, Peter
thanks you for taking interest, here are the details you suggested I
look for:
The dll is a bundle, here is what otool -hv gives:
Mach header
magic cputype cpusubtype caps filetype ncmds
sizeofcmds flags
MH_MAGIC I386 ALL 0x00 BUNDLE 13 2012
NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK
I'm aware of all the documentation you mentioned, however there is a
noticeable different between running the same binaries on 10.5.6 and
10.5.7: in 10.5.6 the bundle file is closed and under 10.5.7 it does
not. To put it differently: while officially dlclose does not have to
do anything, it did under 10.5.6 and seem to do nothing under 10.5.7.
On 27/05/2009, at 17:49, Peter O'Gorman wrote:
Shai Shasag wrote:
My code uses dlopen/dlclose to load/unload dynamic libraries.
Until 10.5.7 dlclose would close the library and the library's file.
When I upgraded to 10.5.7 the library remains open even after dlclose
returns.
In both cases dlclose return value is 0.
I see that the dll file is still open by running lsof (after
dlclose was
called) from the command line:
lsof | grep dll_name
Under 10.5.6 and before this command return nothing - meaning the dll
file was closed.
Under 10.5.7 I get the a line with the name of the dll:
app_name 3434 shai txt REG 14,3 326312 2538026
/path/to/dll/dll_name
Did dlclose change it's behaviour in 10.5.7?
I don't know if dlclose() changed its behavior in 10.5.7, however,
http://opensource.apple.com does not show dyld as being updated in
10.5.7, nor did I see it mentioned in the release notes or security
updates (but I could've missed it).
Is the dll a bundle or a dylib (otool -hv /path/to/dll will show you a
filetype of either BUNDLE or DYLIB)?
If it is a dylib, did you see this section of the dlclose man page?
"
Prior to Mac OS X 10.5, only bundles could be unloaded. Starting in
Mac
OS X 10.5, dynamic libraries may also be unloaded. There are a couple
of cases in which a dynamic library will never be unloaded: 1) the
main
executable links against it, 2) An API that does not supoort unloading
(e.g. NSAddImage()) was used to load it or some other dynnamic library
that depends on it, 3) the dynamic library is in dyld's shared cache.
"
Also, are you sure your code didn't change? dlopen/dlclose keep a
refcount to the opened image, it is not removed until the refcount
reaches zero, if you open it twice, it will stay around until you
close
it twice.
And lastly, dlclose() is not required to do much at all by posix,
which
states "The use of dlclose() reflects a statement of intent on the
part
of the process, but does not create any requirement upon the
implementation", so dlclose could simply be implemented as 'int
dlclose(void * unused) {return 0;}' and be standards conforming, if
your
code can not deal with that case, perhaps it should.
http://www.opengroup.org/onlinepubs/9699919799/functions/dlclose.html
Peter
--
Peter O'Gorman
http://pogma.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden