LoadLibrary and FreeLibrary
Alex
same process.
Has the FreeLibrary to be called if finishing using a DLL? Or if exit from
a process which loaded a DLL, the DLL will automatically Freed from memory?
Thanks.
josh
wrote:
> If the DLL has been loaded, is it Okay to call LoadLibrary
> again from the same process.
> Has the FreeLibrary to be called if finishing using a DLL?
Yes.
> Or if exit from a process which loaded a DLL, the DLL will
> automatically Freed from memory?
Yes, but not releasing what you've acquired is a bad
programming habit. Same as with files, if you open some, you
gotta close them, even though when the program is shut down
they will be closed anyway.
Jonathan Clark
"Alex" <AlexJ...@spam.no> wrote in message
news:<PK8P8.40507$LC3.3...@bgtnsc04-news.ops.worldnet.att.net>...
> If the DLL has been loaded, is it Okay to call LoadLibrary again from the
> same process.
Yes, the kernel uses a reference count, so the DLL is only loaded once.
Actually the kernel only loads one version of a DLL per system so if another
process has loaded c:\program\a_dll.dll and you try to load
c:\winnt\system32\a_dll.dll you will get the first one with an incremented
reference count. This can be changed on XP & 2k, but not the others.
> Has the FreeLibrary to be called if finishing using a DLL? Or if exit from
> a process which loaded a DLL, the DLL will automatically Freed from
memory?
> Thanks.
Yes. You don't need to call FreeLibrary. The other poster states it's a bad
idea not to call FreeLibrary yourself - however I disagree. Calling
FreeLibrary when not necessary is more likely to lead to a program crash
especially if data is shared between the program and the DLL. Plus many DLLs
have memory leaks when loaded and unloaded continously.
Jonathan
"Alex" <AlexJ...@spam.no> wrote in message
news:PK8P8.40507$LC3.3...@bgtnsc04-news.ops.worldnet.att.net...
josh
<newsgrou...@jonathanclark.com> wrote:
> Yes. You don't need to call FreeLibrary. The other poster
> states it's a bad idea not to call FreeLibrary yourself -
> however I disagree. Calling FreeLibrary when not necessary is
> more likely to lead to a program crash especially if data is
> shared between the program and the DLL. Plus many DLLs
> have memory leaks when loaded and unloaded continously.
fix your code so it doesn't leak.
Jonathan Clark
party DLLs, you don't have source code making it impossible to fix memory
leaks unless you have something like my program:
http://thinstall.com/leakbuster
Jonathan
"josh" <jo...@xtreme.net> wrote in message
news:1103_1024336315@l2092in-wllka-2...
Doug Ross
I've ever heard of. If people are actually using broken products, know
they're broken, and proceed to completely work around the solution, I have
no respect for them as programmers. I dunno, maybe there is the odd special
circumstance to require this, but god help us if people start saying, "Screw
it, I'll just use Leak Buster." What ever happened to fixing problems?
I'm sure you'll never do it because of marketing reasons, but you really
should put up something that encourages people to fix the problem before
wimping out and using Leak Buster, because I'm sure that people will. Given
the calibre of the posts in news:microsoft.public.vb.general.discussion, I'd
guarantee it. Maybe give some examples of circumstances where you *really*
need this (of which I can think of none, but who am I to say?).
"Jonathan Clark" <newsgrou...@jonathanclark.com> wrote in message
news:3d0e6d98$0$232$cc9e...@news.dial.pipex.com...
Stephen Kellett
>WTF?! No offense, but Leak Buster sounds like the biggest bandaid solution
>I've ever heard of.
Disclaimer. The company I work for produces a memory leak detection
product. http://www.softwareverify.com
I'd agree. If your code has a problem, you should fix it.
Not commenting specifically on LeakBuster, but more in the general case:
Garbage Collection is not very good for programs that use large volumes
of memory, especially when the program starts to use virtual memory.
Each time the garbage collector makes a sweep it must visit every memory
page in the application in order to accurately check for referencing
pointers. Net result: the entire app is paged out and back in, one page
at a time.
Garbage collected programs also leak memory. What? Did I read the
correctly? Yes. If you examine the toolset for Java software tools,
there are many vendors that market tools that allow you to detect
"loitering objects". A loitering object is an object that should be
collected by the garbage collector, but is not. It should be collected
by the garbage collector because the program has finished using the
object. It can't be collected by the garbage collector because there is
a pointer "somewhere" that is referencing it. These tools allow you to
detect the "somewhere" so you can remove the reference.
With a non garbage collected program, once you delete something its
gone, regardless of if there are other pointers referencing it - so
loitering can't happen.
As to comments about "no more problems with double deletes", well yes,
if you remove the calls to delete by stubbing them out as a garbage
collector does, then a double delete can't happen. That however is
treating the symptom and not fixing the problem. The problem being that
the double delete is often the sign of some other programming error.
Masking these type of errors will thus keep the more subtle bugs hidden
in your program for longer, and as your engineers don't get tripped up
by their mistake (the double delete that no longer happens) they also
are not learning from any design mistakes they may have made.
Real world consulting: We did some consulting with a 3D CAD company.
They tried garbage collection tools to replace the MSVC C runtime
allocator. The models they load routinely use more memory than the
machine's physical memory. On these data models the garbage collected
version of their product was much slower than the non garbage collected
version of their product.
As to the comment about "if you use LoadLibrary() should you use
FreeLibrary()?" The answer is yes you should. An explicit call to
LoadLibrary means you are controlling the lifetime of this DLL. That
means you decide when the DLL is no longer in use. You should call
FreeLibrary() so that the memory used by the DLL (in your application)
can be used for other purposes.
The converse is also TRUE, in that if you didn't load the DLL you should
not be unloading it with a call to FreeLibrary() (unless you absolutely
know what you are doing and why you should do this - I can't think of a
reason for doing this).
Failing to call FreeLibrary() when you are done with the DLL will work,
just your application will not have access to the address space occupied
by the DLL to store data or map other files there. In effect by not
unloading the DLL you have just 'leaked' some memory in your
applications 2GB address space.
For a vendor of a "leak busting" software tool, I'm surprised you would
advise someone to leak an object as (potentially very) large as a DLL.
If you are looking for an advanced memory leak detector and memory
corruption tool:
30 day free evaluation http://www.softwareverify.com
Any problems, just contact support and we'll do all we can to help you.
Regards
Stephen
--
Stephen Kellett http://www.objmedia.demon.co.uk
Object Media Limited C++/Java/Windows NT/Unix/X Windows/Multimedia
If you are suffering from RSI, contact me for advice.
Unsolicited email from spam merchants not welcome.
Jonathan Clark
Garbage collection can have a few downsides, however I think it works
pretty well. Double frees often occur due to race conditions in thread
synchronizations that don't appear in the development environment so using a
conventional memory tool will not help. If it is a critical server
application, the developers cannot afford to have it stop under a debugger
or conventional leak tool.
I'm also working on a version of the garbage collector that does runtime
leak detection. While your program is running it will show the source line
and address of the calling code that created the leak. Nice thing is that
you can leave it running on a server that only leaks under real conditions
and fix the leaks without taking down the server (and no performance hit
either).
This garbage collector has support for incremental generational collection,
which solves the issue of you mentioned with virtual memory. It only scans
pages that have been written to since the last collection, and these pages
are highly likely to be cached-in. It actually has better virtual memory
paging performance than a conventional memory allocator because allocations
touch very few pages, it scale on multi-processor systems, frees are turned
into a NOOP. Currently incremental collection is turned off because I'm
still testing compatibilty with win95.
Applications can and will crash when calling FreeLibrary in the incorrect
order. For example msvcrt.dll keeps a list of exit functions to call
through atexit(), which it calls when it is unloaded through FreeLibrary
(via the system or the user). If another DLL registers an atexit() function
that points to code in another DLL, MSVCRT will crash the program when it
tries to jump to a page that doesn't exsist. If an application is only
calling FreeLibrary when it is shutting down, then it's better to let the
system figure out the free order through the DLL dependancy chain and free
the library for the user. If the DLL is used for a short time during the
middle of execution, then yes, the user should free it themselves.
Jonathan
"Stephen Kellett" <sn...@objmedia.demon.co.uk> wrote in message
news:EwpsI2Ea...@objmedia.demon.co.uk...
Jonathan Clark
war. In school and hobby coding perfect code is an obtainable goal, but
when using 3rd party libraries or DLLs that contain known memory leaks, the
only alternative is to restart your application every once in a while.
Servers that need to maintain high availability cannot afford to do this.
If you lose $1,000 for every server restart then it makes sense to buy the
most reliable hardware you can get. But a recent study shows that 70% of
all server crashes are software related. Leak buster is one way insuring
higher uptimes. It would be great if the code didn't crash or leak in the
first place, but this is the real world.
Personally, I use garbage collection in scripting systems which makes the
interface between C and the script language/virtual machine easy and simple.
It eliminates the need for reference counting smart pointers which are error
prone or inconvenient to use, especially in a mutli-threaded application.
Scripting languages can accelerate development and allow a high level of
user customization. For example, Abuse (http://abuse2.com), which I
published in 1995 through EA still has a player community releasing mods.
Abuse used a copy-compact garbage collector. Letting a garbage collector
take care of freeing script objects greatly simplies the interface between
the two.
Jonathan
"Doug Ross" <4@2.0> wrote in message news:kPuP8.3324$aW1.75920@news...
Stephen Kellett
<newsgrou...@jonathanclark.com> writes
>Double frees often occur due to race conditions in thread
>synchronizations that don't appear in the development environment so using a
>conventional memory tool will not help.
Then the developers should implement their thread synchronization
correctly.
> I'm also working on a version of the garbage collector that does runtime
>leak detection. While your program is running it will show the source line
>and address of the calling code that created the leak. Nice thing is that
>you can leave it running on a server that only leaks under real conditions
>and fix the leaks without taking down the server (and no performance hit
>either).
So you'll be competing with Geodesic Systems. The company that has "the
best in business, Re: Garbage Collection" on their staff. This was the
product I mentioned that didn't deliver the goods in overcommitted
memory situations. BTW: Thats not a quote, but it is a good way to sum
up how they present themselves.
>
>This garbage collector has support for incremental generational collection,
>which solves the issue of you mentioned with virtual memory. It only scans
>pages that have been written to since the last collection, and these pages
>are highly likely to be cached-in. It actually has better virtual memory
>paging performance than a conventional memory allocator because allocations
>touch very few pages, it scale on multi-processor systems, frees are turned
>into a NOOP. Currently incremental collection is turned off because I'm
>still testing compatibilty with win95.
All claims that Geodesic make and which based on what I've seen, don't
stand up to scrutiny in overcommitted memory situations.
>
>Applications can and will crash when calling FreeLibrary in the incorrect
>order.
Thats not what I was commenting on. If you loaded the DLL then should
know when and where to unload it. If your DLL makes an onexit() or
atexit() call then should also be sensible enough to realise that means
you won't be in charge of unloading the DLL, as that is done as part of
the shutdown procedure inside ExitProcess().
>For example msvcrt.dll keeps a list of exit functions to call
>through atexit(), which it calls when it is unloaded through FreeLibrary
>(via the system or the user). If another DLL registers an atexit() function
>that points to code in another DLL, MSVCRT will crash the program when it
>tries to jump to a page that doesn't exsist. If an application is only
>calling FreeLibrary when it is shutting down, then it's better to let the
>system figure out the free order through the DLL dependancy chain and free
>the library for the user.
See above. If people are sloppy enough to think that its acceptable to
load a DLL then unload it incorrectly and rely on a garbage collection
tool to sort out their own mess they shouldn't be involved in software
design, implementation, or quality assurance. The DLL should be loaded
and unloaded correctly.
Garbage collection shouldn't be used as a band aid to cover sloppy
programming. It should be used because you genuinely believe its what is
best for your application. Based on my (and my customers) experiences
with garbage collection I'll be sticking with non garbage collected
applications.
>If the DLL is used for a short time during the
>middle of execution, then yes, the user should free it themselves.
Thats what I was commenting on.
As you can tell I don't like Garbage Collection, I feel in encourages
sloppy design and implementation because "the garbage collector will
look after it".
Anyway, good luck to you. There is a place for Garbage Collection and
there is a place for Memory Leak and Error detection tools.
Stephen
--
Stephen Kellett http://www.softwareverify.com
Memory Validator 30 day evaluation
Jonathan Clark
> best in business, Re: Garbage Collection" on their staff. This was the
> product I mentioned that didn't deliver the goods in overcommitted
> memory situations. BTW: Thats not a quote, but it is a good way to sum
> up how they present themselves.
Yes, I will be competing with them. Geodesic
sells their systems starting at $10k, plus they aren't very well known
(in general) so I think there is plenty of room. I don't think they have
incremental collection, so there are paging problems as you mentioned.
I would like to also collect windows resources and file handles.
> As you can tell I don't like Garbage Collection, I feel in encourages
> sloppy design and implementation because "the garbage collector will
> look after it".
The trend is towards GC, look at c#, java, and any scripting language.
Having to explicitly allocate and free everything is highly error
prone and tedious. While directly memory control is absolutely neccesary
in some cases, having a system in place to take of this for you is
very "freeing". :)
But, I love garbage collection and I've been writing them since the DOS
days, so I'm also biased. :)
Btw, I checked out your software on your web page, and it looks pretty cool.
Must have been a bit of work. :) How long have you been selling it? Seems
like there are a lot of leak detector products, how have you found the
market?
I hear boundschecker sells really well.
Jonathan
GTi
another
> process has loaded c:\program\a_dll.dll and you try to load
> c:\winnt\system32\a_dll.dll you will get the first one with an incremented
> reference count.
If this is true then we all have a problem.
Say I have mylib.dll in my app path and you have mylib.dll in your app path.
They have the same name but have different functions inside.
I think windows must also look at the path for each dll.
"Jonathan Clark" <newsgrou...@jonathanclark.com> wrote in message
news:3d0e2a49$0$225$cc9e...@news.dial.pipex.com...
Jonathan Clark
through LoadLibrary is:
1.. The directory from which the application loaded.
2.. The current directory.
Windows XP: If
HKLM\System\CurrentControlSet\Control\SessionManager\SafeDllSearchMode is 1,
the current directory is searched after the system and Windows directories,
but before the directories in the PATH environment variable. The default
value is 0 (current directory is searched before the system and Windows
directories).
3.. The system directory. Use the GetSystemDirectory function to get the
path of this directory.
Windows NT/2000/XP: The name of this directory is System32.
4.. Windows NT/2000/XP: The 16-bit system directory. There is no function
that obtains the path of this directory, but it is searched. The name of
this directory is System.
5.. The Windows directory. Use the GetWindowsDirectory function to get the
path of this directory.
6.. The directories that are listed in the PATH environment variable.
However, this is not actually the case. I just tried a test program under
windows 95, and it doesn't search the current directory. It always loads
from c:\windows\system unless a full path is specified. I tried it on
Windows XP and it does search the current path. So, if you load a DLL you
should ensure that you always specify the full path to the DLL, or you may
end up loading someone else's DLL. This is through LoadLibrary, I'm not
sure if this is also the case when loading a DLL through an import library.
If so that could be bad because import libraries don't usually specifiy
complete paths to DLLs, so they will always load from c:\windows\system
instead of your app directory.
Jonathan
"GTi" <nos...@online.com> wrote in message
news:BJGP8.645$8X5....@news01.chello.no...
Lucian Wischik
>Not commenting specifically on LeakBuster, but more in the general case:
>Garbage Collection is not very good for programs that use large volumes
>of memory, especially when the program starts to use virtual memory.
>Each time the garbage collector makes a sweep it must visit every memory
>page in the application in order to accurately check for referencing
>pointers.
Not always true. A newish technology (at least for functional programs) is
"regions". Here the compiler does a static analysis to predict entire
large chunks of memory that can for sure be garbage collected. (Even
though this sometimes leaves dangling pointers; the analysis guarantees
that the pointers will never be accessed). I've heard people muttering
about the same for C# but don't know how far it's gone.
--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. www.wischik.com/lu
Stephen Kellett
<newsgrou...@jonathanclark.com> writes
>> So you'll be competing with Geodesic Systems. The company that has "the
>> best in business, Re: Garbage Collection" on their staff. This was the
>> product I mentioned that didn't deliver the goods in overcommitted
>> memory situations. BTW: Thats not a quote, but it is a good way to sum
>> up how they present themselves.
>
>Yes, I will be competing with them. Geodesic
>sells their systems starting at $10k, plus they aren't very well known
>(in general) so I think there is plenty of room. I don't think they have
>incremental collection, so there are paging problems as you mentioned.
I can't comment on their implementation details. During the consulting
between my customer and Geodesic I was kept out of the loop because of
obvious conflicts of interest. I'd be surprised if they don't do
incremental collection based on the calibre of the founders.
>I would like to also collect windows resources and file handles.
Memory Validator does this.
>
>> As you can tell I don't like Garbage Collection, I feel in encourages
>> sloppy design and implementation because "the garbage collector will
>> look after it".
>
>The trend is towards GC, look at c#, java, and any scripting language.
I agree, thats because there is also a trend to using less skilled
labour, which leads nicely to your next point. I'm not saying that
someone is not skilled because they use a GC system. Just that the newer
languages prevent you having as much control as before and that does
allow a lower skill level to get a similar result.
> Having to explicitly allocate and free everything is highly error
>prone and tedious. While directly memory control is absolutely neccesary
> in some cases, having a system in place to take of this for you is
>very "freeing". :)
>
>But, I love garbage collection and I've been writing them since the DOS
>days, so I'm also biased. :)
>
>Btw, I checked out your software on your web page, and it looks pretty cool.
Thank you.
>Must have been a bit of work. :)
Yes it was. We used to use the existing tools provided by our
competitors for our consulting work. The software was borne out of
frustration of dealing with vendors that did not care for their
customers, did not provide decent customer support, or fix bugs that
were reported to them. Also a lack of decent analysis features was a
driving force. We've spent a lot of time creating it and we update it at
least weekly with performance improvements, new features and so forth.
>How long have you been selling it?
Memory Validator has been in use at a few companies for quite sometime.
We launched the product publicly on April 15, 2002. We will be launching
more products later this year.
>Seems
>like there are a lot of leak detector products, how have you found the
>market?
We are pleased with our progress.
>I hear boundschecker sells really well.
Probably, they've been doing this for 10 years. Quite a headstart. They
lost a lot of their senior staff last year. Many of them are now at
Wintellect, and Matt Peitrek is, I think, involved with an internet
company of some sort.
I was a beta tester for Purify, back when Purify was only available on
Solaris from Pure Software Inc. (sold to Atria, sold to Rational). Its
kind of interesting that 10 years later I work for a company that is a
competitor of theirs.
I couldn't tell from your web page, which country are you based in?
Stephen
--
Stephen Kellett http://www.softwareverify.com
Memory Validator Automated Memory Leak Detection
Stephen Kellett
<nos...@online.com> writes
>> Actually the kernel only loads one version of a DLL per system so if
>another
>> process has loaded c:\program\a_dll.dll and you try to load
>> c:\winnt\system32\a_dll.dll you will get the first one with an incremented
>> reference count.
>
>If this is true then we all have a problem.
>Say I have mylib.dll in my app path and you have mylib.dll in your app path.
>They have the same name but have different functions inside.
>I think windows must also look at the path for each dll.
Also, Windows uses copy on write, so if you modify your DLL once you've
loaded it, Windows will provide a private copy of the DLL for use by
your program. I can't remember if it will provide a private copy for the
entire DLL or just the pages of the DLL that you've modified.
Jonathan Clark
> Probably, they've been doing this for 10 years. Quite a headstart. They
> lost a lot of their senior staff last year. Many of them are now at
> Wintellect, and Matt Peitrek is, I think, involved with an internet
> company of some sort.
>
> I was a beta tester for Purify, back when Purify was only available on
> Solaris from Pure Software Inc. (sold to Atria, sold to Rational). Its
> kind of interesting that 10 years later I work for a company that is a
> competitor of theirs.
Wow, I didn't know that. Last time I talked to Matt a few years ago
he said he had no intention of leaving because we was getting paid very
well and he also has a family who he didn't want to move. Where
is he now?
> I couldn't tell from your web page, which country are you based in?
My company is based in California, but right now I'm living in London
for kicks. How about you? It says .uk in your email (is that a valid email?)
You should send me your contact info. It's always useful to know more
low level coders. :)
Jonathan
http://jonathanclark.com/contact
Stephen Kellett
<newsgrou...@jonathanclark.com> writes
>Wow, I didn't know that. Last time I talked to Matt a few years ago
>he said he had no intention of leaving because we was getting paid very
>well and he also has a family who he didn't want to move. Where
>is he now?
Well I could be wrong, I was basing this info on the fact that the last
article I read that was written by him said that he was involved in an
internet startup. Maybe there is more to that than meets the eye. I
don't know any of the NuMega/Rational people so that what I've said with
a pinch of salt. It doesn't surprise me he gets paid well, hes a
talented guy.
>My company is based in California, but right now I'm living in London
>for kicks. How about you? It says .uk in your email (is that a valid email?)
Yes.
I'm 70 miles north of you, just North of Cambridge.