Subject: RE: malloc() question..
From: [email-masked] (Wade Richards)

17 Nov 1997 17:32:59 -0800
Message-ID: <c=US%a=_%p=ENTERPRISE%l=[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Hi, Greg.

It looks like you've hit one of the hardest sort of bugs to debug: a
memory corruption bug.  More specifically, a memory over-run.  To help
you find this sort of thing yourself, here are the clues:  1) GPF inside
"malloc".  2) adding 16 to all your malloc calls helped a little (but
the problem still exists).

In simple terms, what is most likely happening is that you are writing
to some memory that you didn't allocate, just past the end of the memory
that you did allocate.

In the computer's memory (the "heap"), the run-time library keeps
pointers and "stuff" in the memory that you aren't using, so that it can
keep track of what is in use and what's available.  Some of those
pointers are right at the end of the memory you've allocated.  If you
allocate 10 bytes from malloc, and then you copy "this is a long string
to cause a problem" into that 10 byte space, you will corrupt the data
that malloc needs to know what is free.  The copy will probably work,
the rest of your code will seem to work fine, but the next time you call
malloc(), free(), realloc(), or any other memory function, that's when
the GPF will occur.

So, the thing to do is read over your code, looking for places where you
might be writing more data into a buffer than you've allocated space
for.  One other thing you can do is put lots of calls to "heapcheck()"
(or whatever the function that checks the heap for validity is on your
system) in your code, and stop as soon as one fails.  This way you know
that the problem occurred between the last successful heapcheck and the
first failed one.

	--- Wade

PS: The advice "add 16 to all malloc calls" is probably the WORSE advice
you could have taken.  It will not solve your problem, it will just make
it harder to hide.  Remove those extra 16 before you try everything
else.  Remember: you should know exactly how much memory you will need
for each allocation.  If you are adding some "fudge factor", then you
are simply guessing.

>On 14 Nov 97 at 7:11, Keet / Foxbird <[email-masked]> wrote:
>> 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,
>> 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]
>
>
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".