jdm5548@diamond.tamu.edu (James Darrell McCauley) (08/10/90)
NOTE: Probably another novice question. Those easily irritated should skip this message. Thank you all for the responses to my last question. [I learned that you don't ask questions unless you've had enough sleep to really think about your problem ;-)] This one (I don't think) is not as trivial as my last. Here's what I get from 'dbxtool' when I try to print the value of a variable at the point where my program crashes: =]Reading symbolic information... =]Read 2365 symbols =](dbxtool) print table[k] =]`fillab`fillab`table[`fillab`fillab`k] = 0x40a00000 =](dbxtool) print table[k][2] =]warning: core file read error: data space address too high =]bad data address =](dbxtool) 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? I tried to isolate the problem in the infamous "test.c," but to no avail. I didn't think it appropriate to include all 1870 lines. THEREFORE, please don't flame for not including source. BTW, 'lint *c' doesn't mention anything unusual. Sun OS 4.0.3 on Sun 3/60 with 12 MB of memory. When including /usr/lib/debug/malloc.o & /usr/lib/debug/mallocmap.o at link time, I don't even get to the error described above. It complains: =]free: bad block size (1003204457) at 0x22d30 =] =]IOT trap (core dumped) I haven't tracked this one down yet. Something tells me that I'm going to have a heck of a time porting this to a PC (and it's only 30% complete) :-( Sorry for all the verbage. Please e-mail responses unless you think it would be more appropriate to post. Many thanks for your patience and suggestions. --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - James Darrell McCauley jdm5548@diamond.tamu.edu Dept of Ag. Engineering (409) 845-6484 Texas A&M University, College Station, Texas 77843-2117, USA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
jdm5548@diamond.tamu.edu (James Darrell McCauley) (08/11/90)
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.