Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: malloc bug ?
Message-ID: <1991Mar20.233843.19601@athena.mit.edu>
Date: 20 Mar 91 23:38:43 GMT
References: <1991Mar20.142604.29925@fmrco>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 27

In article <1991Mar20.142604.29925@fmrco>, harold@fmrco (Harold Naparst) writes:
|> I have a program which is bombing with a SEGV in a call to malloc.

  When your program SEGVs inside malloc, the explanation is almost always that
you have corrupted the malloc arena at some point in the past.  Malloc tries
to use the corrupted header information in the malloc arena and dies.

|> Curiously, the problem goes away in Saber-C.

  This is curious, but not completely incomprehensible.  Saber changes the
run-time environment enough that something that may be corrupting the malloc
arena in a compiled program may not to the same thing inside Saber, possibly
because there's more free room at the end of memory blocks allocated by
malloc, so when your program overwrites a block at some point, it doesn't go
into the header of the next block.

  There is pretty much no way for us to help you figure out why your program
is SEGVing given only the information you have provided thus far.  You're
probably going to have to track down this one yourself.  Be aware that there
are several debugging malloc libraries available in the various source
newsgroup archives.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710