Path: utzoo!attcan!uunet!ncis.tis.llnl.gov!lance.tis.llnl.gov!spengler
From: spengler@lance.tis.llnl.gov (Tom Spengler)
Newsgroups: comp.lang.c
Subject: Re: Turbo C 2.0 MaLfUnCtIoNiNg?
Keywords: Turbo C 2.0   bug   malloc
Message-ID: <896@ncis.tis.llnl.gov>
Date: 20 Jul 90 17:50:15 GMT
References: <1217@kubix.kub.nl>
Sender: news@ncis.tis.llnl.gov
Organization: University of California, Berkeley
Lines: 24

In article <1217@kubix.kub.nl> mad-2@kub.nl (C. Wekx) writes:
>
>Yo folks,
>
>
>	does anyone happen to know why Turbo C 2.0's malloc
>function is malfunctioning? They do not always signal an out of memory
>situation, but overwrite the first part of their segment instead.
>
>
>
>
>						Joris

On a couple of occasions, I was *sure* that some function in the malloc() 
family was misbehaving, but not so.  It was me, and the cause in each case was
a bogus free().  A free() on a wrong pointer will corrupt the free list.
The results of this corruption may not be immediately seen, but at some point,
the program will fail in puzzling, and usually catastrophic, ways on DOS.

So, check all pointers returned by malloc() and friends, and check all your
free()s.

Hope this helps.		--Tom Spengler (spengler@tis.llnl.gov)