Date: Tue, 28 Sep 1999 09:37:44 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: GAMMELJL AT SLU DOT EDU cc: djgpp AT delorie DOT com Subject: Re: problem with malloc.c attn: Michael Bukin and Eli Zaretskii In-Reply-To: <01JGGU5V1COM8WW5WR@SLU.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 27 Sep 1999 GAMMELJL AT SLU DOT EDU wrote: > There is no doubt that > an effort is being made to free (or delete) g twice when g is used > in the last two lines. > The problem is: what to do about this. You need to fix your code to avoid calling `free' more than once. > It is an absurd situation. > Other compilers, such as the Watcom C/C++ compiler, and indeed the > Delorie port of the gnu compiler with the old malloc.c, have no trouble. > Why should the Delorie port of the gnu compiler with the new malloc.c? This is a misunderstanding. The new malloc does NOT introduce the bug. The bug of `free'ing the same memory chunk twice was in the old malloc as well, but the old version wasn't paying attention because it didn't care about this particular bug. The new version does. I don't know how do other compilers implement malloc/free, but a buggy application code (yours) invokes what's called ``undefined behavior'', which in English means ``anything can happen''. The right way to solve this is to fix your code, not to blame the library for misbehaving when you violate the rules of the game.