Subject: Re: malloc() question..
From: [email-masked] (Fernandes, Hilton)

15 Nov 1997 09:12:25 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
To: Keet / Foxbird <[email-masked]>, [email-masked]
Cc: "Fernandes, Hilton" <[email-masked]>

On 14 Nov 97 at 7:11, Keet / Foxbird <[email-masked]> wrote:

> 
> I've recently made some additions and changes to a program of mine, which
> filters out certain sets of characters (IE: ^01^ ) and turns them into ANSI
> escape sequences for color. Needless to say it's for a telnet server type
> application. The only problem is, that it seems to crash at a certain spot
> every time (this spot can vary depending on the settings). I've gone
> through and looked at debug code, and scanned over all the source and found
> the line that caused the problem. The baffling thing about this line is
> that it's the line that calls 'malloc'? It takes the length of a string,
> adds a few to it, mallocs the memory, and then assigns a string into it.
> This line is called many, many times before this, and works fine each time,
> but it seems to trip up after a certain number of calls. I've asked a few
> people what to do, and some told me it was some kinda of memory pointer
> problem, and that I should add 16 to all the malloc calls I make. Did that,
> and it progresses quite a bit farther but it then it drops out on another
> malloc call. So now I'm lost as to what to do. Can anyone offer any help?
> 
> - Greg Neujahr
>   [email-masked]

Hi!

You haven't told us what's the specific problem.  So let's guess: either you
have a pure malloc() bug, or malloc() is working, but returns a null pointer. 
BTW, you'd better check for them.

Since the null pointer is a more probable (and easier :-) alternative, let's 
think about it.  AFAIK, there are two motives for that: either there's not 
enough free memory, or there is but it's badly fragmented.

In the former case, you probably got what people call memory leakage: you
simply forgot to release the memory you've allocated.  The latter is more
interesting: memory fragmentation means that there are lots of free memory
blocks, but they're not big enough to satisfy your demand.  An alternative
reason to memory leakage it is that you simply don't have enough memory to run
your app.  Nowadays, with huge memory sizes and virtual memory, that shouldn't
be the problem.

To solve a memory leakage bug, you need to match each memory allocation with
its corresponding release.  The memory fragmentation problem may have several
alternative solutions.  An easy one is to allocate memory in blocks whose size
is the upper multiple of an adequate number.  I mean, if the number you chose
is 16, then when instead of allocating 18 bytes, you allocate 32 bytes, since
32 is the upper multiple of 16.  However, if you must allocate 48 bytes, then
you allocate 48, since 48 is an integral multiple of 16. 

The idea of a upper multiple of 16 can be summarized by the C formula:
	upper_mult = 16 * ((orig_chunk / 16) + ((orig_chunk % 16) == 0));

The problem is that 16 is not the best universal number to base this scheme. It
depends on the application you have and on the storage allocator.  If you
really detect that memory fragmentation is your problem, you have to try some
numbers.  16 was a good number in DOS times, when the DOS allocator had a bug
related to this number.  (Now that we have full 32 bits operating systems, that
shouldn't be a problem. :-)  But be generous with that number.  Remember that 
the higher number, the greatest the memory chunks available when memory is 
badly fragmented. 

I hope that helps.

Regards,
++Hilton
----
Hilton Fernandes
[email-masked]
http://www.geocities.com/SiliconValley/Lakes/5657
URLs and help on C++ programming and Object-Oriented Design
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".