Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!diamond!jdm5548
From: jdm5548@diamond.tamu.edu (James Darrell McCauley)
Newsgroups: comp.lang.c
Subject: Re: data space address too high?
Keywords: malloc, dbx, high address
Message-ID: <7344@helios.TAMU.EDU>
Date: 11 Aug 90 09:16:10 GMT
References: <7295@helios.TAMU.EDU>
Sender: news@helios.TAMU.EDU
Reply-To: jdm5548@diamond.tamu.edu (James Darrell McCauley)
Organization: Texas A&M University Agricultural Engineering Dept
Lines: 37

In article <7295@helios.TAMU.EDU>, I write:
<stuff deleted>
|> 
|> Here's what I get when I print the address of array elements:
|> 
|> =] (lots of stuff deleted)
|> =]&table[15][3]=152048
|> =]&table[15][4]=152052
|> =]k = 16
|> =]&table[16][1]=1084227588
|> =]&table[16][2]=1084227592
|> =]&table[16][3]=1084227596
|> =]&table[16][4]=1084227600    <=== assignments begin to these addresses
|> after this
|> =]Bus error (core dumped)
|> 
|> Could someone explain to me what this may mean? I assume it has something to
|> do with extensive use (overuse) of malloc, but malloc didn't return any
|> errors. Just a guess, but could I be allocating memory that's not
accessible?

|> BTW, 'lint *c' doesn't mention anything unusual. Sun OS 4.0.3 on Sun 3/60
                                                    ^^^^^^^^^^^^

Later, I read in a README file for a package called ZPLOT:
                                      ...  This is NOT a bug in zplot,
        it is a known bug in Sun's system memory allocation algorithm
        that arises from calls to malloc() and that's where it crashes
        or misallocates memory. Sun says they will be fixing that in
        their upcoming SunOS 4.1 release.

Does anyone know about any bug in Sun's malloc()? Should I take my
problem to the
Sun newsgroup? I would really like to hear from ANYONE who can provide any
insight.

--Dead-in-the-water.