From:	"Christopher Nelson" <paradox AT gye DOT satnet DOT net>
To:	<djgpp AT delorie DOT com>
Subject:	Re: malloc causing GPF?????????????
Date:	Wed, 30 Jun 1999 14:51:50 -0600
Message-ID:	<01bec33a$607bd400$LocalHost@thendren>
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 4.71.1712.3
X-MimeOLE:	Produced By Microsoft MimeOLE V4.71.1712.3
Reply-To:	djgpp AT delorie DOT com

>I am writing a program. Today, when it was running, it
>suddenly exited with a GPF! when i used Symify to know
>the cause of the problem, it showed that malloc was
>the function at top of stack!!!!! (i.e. It was the one
>being executed!)... I was very perplexed! I dunno how
>to begin debugging!! I don't even know the cause of
>the problem!


usually when that happens it's because you have rogue pointers floating
around somewhere in your program.

>i) Could the problem be in MY OWN code? How? Why did
>the GPF occur in malloc itself?? What kind of bugs can
>cause this GPF? how can I know the cause of the
>problem?

often a rogue pointer can overrun some of that information that malloc uses
to keep track of memory blocks.  that can cause malloc to have a heartattack
and die.

>ii) Did a similar problem occur to anyone? did he know
>the cause of it? if so, would u please tell me how did
>it happen?

it's happened to me several times, and usually it's because i wrote messy
code.

>iii) Could the problem be in malloc itself?? My
>program calls malloc() and free() TONS of
>times!!(about 800 times, and may  be larger!). Is
>there a problem regarding malloc and free when called
>a LOT of times? If this is the cause, what is the
>solution? I have some replacements for malloc. but i
>want to know HOW to compile the libraries? (The only C
>compiler i have is DJGPP)

it IS possible to fragment the allocation heap so much that you can't get
enough memory, but that doesn't usually cause malloc to die, it just returns
a 0.  i don't think that calling malloc and free some 800 times is a
problem.  i have a library that makes thousands and thousands of allocations
(it's a testbench for a heap-allocation routine that uses malloc as a
backing store), and it has no problem.

another good way to check this is to use YAMD or something similiar.  (it's
a malloc debugger-keeps track of memory usage and helps catch rogue pointers
by terminating the program as soon as a pointer writes somewhere it ought
not.  in addition, it can pad the memory blocks to check ans see if you're
doing buffer over and under runs.

    -={C}=-

- Raw text -