harold@fmrco (Harold Naparst) (03/20/91)
I have a program which is bombing with a SEGV in a call to malloc. I am curious as to what could be causing this. I am attempting to allocate about 1.5 Megabytes. I have a SUN 4 running 4.0.3, but have been able to reproduce the bug on a Sun 3 as well. Curiously, the problem goes away in Saber-C. Harold Naparst -- Harold Naparst | (uunet!fmrco!harold) Fidelity Investments | (617)-570-2587 82 Devonshire St., #I40B | The opinions expressed herein are not those Boston, MA 02109 | of my employer.
jik@athena.mit.edu (Jonathan I. Kamens) (03/21/91)
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
gwyn@smoke.brl.mil (Doug Gwyn) (03/21/91)
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. >I am curious as to what could be causing this. The usual cause is that the application has corrupted some of the free-space arena, damaging the bookkeeping information (such as pointers in a linked list) that the malloc()/free() implementation relies on to keep track of free space. Then later, when malloc() is looking for free space, it gets confused by the damaged information and falls off the deep end.