[WriteLog] Software Memory Leak

Gerry Hull windev@inetmarket.com
Thu, 03 Jan 2002 08:46:11 -0500


Hey Rick and Writelog folks,

Since I was the guy who started this memory leak thread, let's bring it
back into the Writelog domain, so that users can relate to the (not yet
clarified) issue.  So, bear with me for a minute and i'll tie this all
together for us Writelog users.

Yes, all the modern Windows operating systems are virtual memory, which
means, essentially, they won't run out of memory in normal circumstances.
However, due to a fact of history and Windows design goals, there are
multiple types of memory used by the Operating System in Windows
95/98/ME which are NOT virtual memory.  They important ones here are User
and GDI, and are used for window management and graphics (GDI stands for Graphic 
Device Interface).  User/GDI in Windows 95/98/ME is limited to 64K each,
even if you have a Gigabyte of memory in your machine with a 100GB hard
disk.  Applications like Writelog talk to the Windows operating system
to "do their thing."  There are rules about how you talk to Windows, and
if not done properly, things like a memory leak can occur.  Under
Windows NT/2000/XP, User/GDI is not limited to 64K.

BTW, you can actually monitor the memory usage in your Windows 98/95/ME
box by running the System Monitor application, which can be found under
Accessories->System Tools.  If it is not found, it is in the Resource
Kit for each operating system.  It will show the available memory all
the time.

It gets a bit murky with complex applications like Writelog, becuase
there are actually many layers of software between the application and 
Operating System.  So, a bug of this sort may not be in the actual
applications software.  Often, the developer has to work around bugs
in "middleware" or the Operating System itself.

Now, to the original issue at hand.  During CQWW CW at VE1JF (M/S) and
during the ARRL 10 Meter contest @ my QTH, the Windows 98 machines 
I used would become very slugish after about 10-12 hours of operation.
New windows could not be opened, and painting (drawing of
windows) became very slow.  Also, the fonts on windows changed to a
different font.  This is a telltale sign of an out-of-memory condition
in Win 95/98/ME.  By simply closing Writelog and reopening, the problem
goes away.  But, if your running at +200 hour, who wants to shut down
and restart.  If the problem goes away by shutting down and restarting,
it's a pretty good bet that the "problem" is Writelog related.  These
are very hard problems to fix, because the "bug" could be a simple leak
of a byte or two, but, called 10s of 1000s of times by a program, causes
major issues.

My point in the thread was to try and characterize what configuration
causes the issue, and help Wayne track it down.  Is this a ShowStopper
bug?  Naw, just an inconvenience.

73,

Gerry, W1VE/VE1RM

> What Len is saying is quite true.  And you have to consider that Win2K with
> Win9x/ME are all "virtual memory" operating systems.
> 
> Time for a 20,000 foot view of virtual memory..
> 
> What does "virtual" mean?  Nothing more than the fact that when RAM is about
> to be used up the OS will take some that hasn't been used in a while and
> write it out to the "swap file".  This frees up that chuck of RAM to be used
> by an active program (process actually). The part of the OS called the
> "memory manager", along with some help from the hardware can make any
> section of RAM appear at any address within the 4GB range represented by a
> 32 bit address.  So if your hard disk is big enough to afford a 4GB swap
> file then you can have a full 32 bits of "virtual" memory in use at once.
> Even if your machine only has, say 128MB.  Having said that, let's make it
> perfectly clear that this would be a *very* ridiculous set-up.  But in
> theory it's possible.
> 
> Let's look at the problem on a more practical note.   Let's say that you
> have 128MB along with a 256MB page file.  As the 128MB or real, physical
> memory is used up sections that haven't been used in a while will get
> "swapped out" (written) to the page file and the newly freed up RAM is put
> back into the service of a different process or program.  As a rule of
> thumb, try to have as much RAM as you can afford and make the swap file the
> same size or twice as large.
> 
> If your disk often sounds like a popcorn machine then your computer is
> really hitting the swap file hard and you need more RAM.  Incidentally,
> there is a range of opinion as to what the ratio of swap file size to RAM
> size should be.  I use 2:1, mostly because that was a recommended practice
> that I read about somewhere.  Others can make good arguments to move the
> ratio up or down.  If you are using up what virtual memory that you have (in
> our example, 384MB) then you might be able to delay the agony by increasing
> the size of the swap file - but it will cost you in performance.  RAM is
> orders of magnitude faster than disk!
> 
> With 128MB on a machine running Win2K Server, I often heard the disk
> swapping.  I might just do something as simple as activate a window in the
> background that I haven't used in a while.  I would often be subjected to
> 2/5/10 seconds of "popcorn popping" later before the window would finally
> pop up.  I increased the RAM to 512MB when prices were cheap.  Now I rarely
> hear the disk swapping.  And things seem a lot faster.
> 
> Now back to WriteLog.  WriteLog would probably have to be working one one
> *huge* log to push the limits of a reasonably set up machine.  What *is*
> more poisonous is what Len talked about.
> 
> Imagine a program that asks for a chunk of memory as part of an operation;
> and that this operation is done over and over again.  The chunk of memory
> was only meant to be used temporarily, but the programmer forgot to release
> it in some other part of the program.  Bingo, you've got a memory leak.
> Over time this *can* eat up your RAM and swap file.  This is where Perfmon,
> the NT/WIn2K/WinXP performance monitor, can help you track memory usage.
> 
> Hope this hasn't been too boring for folks.
> 
> Cheers,
> -ricK7log