Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!SNOWHITE.CIS.UOGUELPH.CA!mike
From: mike@SNOWHITE.CIS.UOGUELPH.CA
Newsgroups: comp.sys.sgi
Subject: problem with malloc
Message-ID: <9010252231.AA23626@snowhite.cis.uoguelph.ca>
Date: 25 Oct 90 22:31:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36

Ian:

    I probably won't be the first or the last to say this, but you've probably
got a loose pointer on your deck somewhere.  If you write into memory that you
didn't allocate (by far the most popular way to do this is to scan either
forwards or backwards off of a chunk of memory you got from 'malloc', but there
are other, more interesting, ways to do it too), then sooner or later you'll
stomp on the memory that 'malloc' and 'free' use to maintain their sanity.
The result usually looks something like what you describe, plus or minus a
few Rolaids.

    I have found (through painful personal experience) that tracing this kind
of problem is difficult but not impossible.  The call that core dumped is 
almost always totally blameless, because the memory stomp could have happened
quite some time ago in program terms.  To help you out with this, SGI provides
a really neat option for memory debugging called 'mallopt'.  If you look at
the man page for this baby you'll find that just by putting:
	mallopt(M_DEBUG, 1);
early in 'main', 'malloc' and 'free' will perform a full scan of their internal
structures each time that they are called.  This should help you in tracing
down your varmint pointer by letting you know that something is goofed up 
as soon as possible after it happened.  Of course, you pay for this checking
by having to put up with a (ahem) noticeable decrease in speed of operation
of the two system calls in question.

    In more desperate straits I have even put my own front end on malloc so
that I allocated an extra 2k each time I asked for space, and positioned the
requested space in the middle of the big chunk (leaving 1k of safety buffer
on each side), just to see if it was an overscan problem.  If things get 
really bad you could try that too.

    Good luck.

>From an informal introduction to C:      | Mike Chapman
        C looks a lot like               | Grab Student, University of Guelph
        Pascal with a hangover.          | mike@snowhite.cis.uoguelph.ca