Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!pyramid!csg
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.pyramid
Subject: Re: Memory fault - core dumped
Message-ID: <138294@pyramid.pyramid.com>
Date: 19 Dec 90 19:44:56 GMT
References: <1990Dec19.031913.24197@massey.ac.nz>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 26

In article <1990Dec19.031913.24197@massey.ac.nz> K.Spagnolo@massey.ac.nz (Ken Spagnolo) writes:
>telepage: 23739 Memory fault - core dumped

This is adb's message when it receives a SIGSEGV, or segmentation violation.
What this means is that the program tried to reference memory outside of its
allocated bounds. In C, this almost always means dereferencing a bad pointer.

One of the most mystifying problems in UNIX programs is how they can be given
apparently identical conditions, and produce varying results. The answer, of
course, is that the conditions aren't *quite* identical; and for this class of
bugs, I frequently find that my dereferenced pointer is poking around in the
environment table. Big environment, program runs. Small environment, program
gets a SIGSEGV. Note that programs spawned by cron typically have very small
environments (HOME, PATH, SHELL, and not much more), while those spawned by
users typically have huge environments.

To try reproducing this, start a new C shell, then 'unsetenv' everything in
the environment. (You can use printenv to find your environment variables.)
Then invoke your program, and see what happens.

You can also look around malloc() calls, to see if pointers are not always
being handed back correctly; also check to make sure that the return value
from malloc is error checked! A lot of programs don't do this, resulting in
inexplicable and unreproducable errors when virtual memory gets tight.

<csg>