Subj : Re: malloc()
To   : borland.public.cpp.borlandcpp
From : waking
Date : Wed Jun 23 2004 12:20 am

On Tue, 22 Jun 2004 17:59:23 +0200, Jan Vernimmen <j.vernimmen@chello.nl>
wrote:

>if ( strlen( szInput ) > strlen( txtBuf ))

Is the buffer *guaranteed* to have a terminating nul character
within its boundaries? Especially on the first iteration. i.e. - 
Is the *initial* allocation of an adequate size and zero-filled
or zero-terminated? Have you tried the program (without your
work-around of the added byte) using calloc instead of malloc?

Is the buffer *guaranteed* to be at least one byte larger than 
strlen( txtBuf )?

>The program sometimes (once a week, once a day, suddenly every hour) 
>corrupted, changed its character-fonts (saving data was sometimes possible at 
>this moment) and then stopped.
>at this point the malloc went wrong, sometimes, unpredictable.
>Also points where I had to update strings due to program results, the same 
>happened.

Usually the result of one or more of the following:

(1) A pointer to allocated memory was freed more than once.
which will/may confuse the allocator.

(2) Data overruns have occurred, corrupting critical data
in memory. e.g. - Writing past the end of an array.

(3) An invalid pointer was used, causing data to be written
to an arbitrary address. (Could be due to invalid/old pointer
contents, or using the wrong word size.) N.B. - Since this
app was converted from 16-bit to 32-bit, word size changes
have to be looked at with care.

(4) A memory leak (failure to free memory) in an iterative
procedure has caused depletion/fragmentation of the heap, 
with the result that an allocation attempt fails.

(5) Undetected stack overflow has occurred, resulting in corrupt
stack data or overwrites of heap locations adjacent to the actual
end of the stack.

(6) Given a multi-module program, care must be taken to ensure that
all modules are built with the same options. e.g. - Alignment: byte, word,
double-word, quad-word, etc. Allocating a memory block in one module
and freeing it in a different module may also be a possible source of
problems.

>using malloc in a 32-bit system always gives a plural of a 4-byte space.
>When I reserve 13 bytes (malloc(13)) the result is a 16 byte room, so the same 
>as when I should have done malloc(16).
>malloc(17) gives back the same room as malloc(20) and so on.

This is to be expected. The memory manager requires space to
keep its own control data for managing allocations. It may also do
optimized allocations to take advantage of efficiencies realized via
boundary alignments.

Suggestions:

(1) Make sure that the program is built with the option to Check for Stack
Overflow enabled..

(2) Build and test the program using a memory/bounds checker such as
CodeGuard or MemProof. If you have the 5.02 Development Suite, then
you already have CodeGuard. MemProof is a free download from
http://www.automatedqa.com/downloads/memproof.asp
When testing, remove your "work-around". (+2)

(3) *Always* test for failure of *every* allocation attempt in your programs.


--
Wayne A. King 
(waking@idirect.com, Wayne_A_King@compuserve.com)

.