Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!central!csccat!egsner!swsrv1!toma
From: toma@swsrv1.cirr.com (Tom Armistead)
Newsgroups: comp.unix.sysv386
Subject: Re: malloc() problem on sysv386
Message-ID: <1991May24.024307.29104@swsrv1.cirr.com>
Date: 24 May 91 02:43:07 GMT
References: <1991May23.094026.18969@hollie.rdg.dec.com>
Organization: Software Services: Garland, Tx
Lines: 32

In article <1991May23.094026.18969@hollie.rdg.dec.com> moore@forty2.enet.dec.com (Paul Moore) writes:
>I've recently had this error occuring when malloc is called running an
>application on ISC SVR3.2 (observed from the sdb debugger):
>
>   memory fault (11) (sig 11)
>
>The man page for signal(3) indicates that this is a segmentation violation. 
>
>The problem only occurs when malloc() had been previously called in the code
>execution path; it doesn't appear when this code path isn't executed.
>
>The problem doesn't appear at all when I run the very same application on
>Ultrix.
>
>Any ideas, anyone?
>
>- Paul

These type of errors are usually caused by 1 of 2 things (or both).
  1. Freeing an un-malloc'd or already-free'd pointer.
  2. Overwriting the end of a malloc'd area.

In either case, it's usually on the next malloc() call that you get the core
dump (sometimes *several* malloc's later).

And these types of errors are generally a bitch to find...

Tom
-- 
Tom Armistead - Software Services - 2918 Dukeswood Dr. - Garland, Tx  75040
===========================================================================
toma@swsrv1.cirr.com                {egsner,letni,ozdaltx,void}!swsrv1!toma