Subj : Re: malloc()
To   : borland.public.cpp.borlandcpp
From : Jan Vernimmen
Date : Wed Jun 23 2004 04:59 pm

Hello Wayne,

Thanks for your detailed comment!
My reactions on the specific points, see below>

Jan.



Wayne A. King wrote:
> 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 )?
> 

I've written the strings, their length and the ASCII values to a debugfile.
I cannot find errors.

> 
> 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.
>

I'll check again.


> (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.
>

Can I test this? malloc() returning zero or something like that?

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

Check for Stack Overflow enabled.. Done!
> 
> (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.
> 

I did. All moduls are built in the same project, now and then with "Build All"

> 
>>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.
> 

I'll follow your suggestions. I'm already using MemProof.

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

.