Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!cc-server4.massey.ac.nz!K.Spagnolo
From: news@massey.ac.nz (USENET News System)
Newsgroups: comp.sys.pyramid
Subject: Re: Memory fault - core dumped
Message-ID: <1990Dec20.230417.12597@massey.ac.nz>
Date: 20 Dec 90 23:04:17 GMT
References: <1990Dec19.031913.24197@massey.ac.nz> <138294@pyramid.pyramid.com>
Reply-To: K.Spagnolo@massey.ac.nz (Ken Spagnolo)
Organization: Massey University Computer Centre
Lines: 39

In article <138294@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>In article <1990Dec19.031913.24197@massey.ac.nz> K.Spagnolo@massey.ac.nz (Ken Spagnolo) writes:
>>telepage: 23739 Memory fault - core dumped
>
>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.

Thanx for your response.  I had the programmer involved do what you
said, but to no avail.  All the pointers, etc. look ok and there are
no mallocs or other dynamic memory allocations going on either.  Its
a pretty straight forward piece of code.

Perhaps some more info is needed.  Though the problem has recently
occured only with the telepage program, when it began (before the
kernel was rebuilt), the first thing to get hit was sh.  This
happened upon reboot while running rc.  Another program to be hit
was EaseScreen, which is third party software.  One common thing
about these three programs, is that they all are part of the att
universe (our system administration runs under att, telepage was
compiled under att and EaseScreen is from a SysV house).  So
perhaps there is a problem in an att library somewhere?

Of course, this could be a physical problem caused by the brown
out (sh dumped on reboot right afterward), but I'd like to hear
any comments, before I go to our local rep with a problem that
is not easy to reproduce.

Thanx again.  Happy Holidays.

Ken

PS  Who is actually reporting this (not terribly informative) error
    message?  The kernel?  In what way would adb be invloved?