bause@anton.informatik.uni-dortmund.de ( ??? Bause ???) (08/01/90)
A friend of mine is using Zortech 2.0. He uses hashed search tables and binary tree search tables. After some insertions into both tables he gets the error message: heap corrupted. Is this is known error of Zortech's C++? Please answer by e-mail to bause@unido.uucp Falko
bright@Data-IO.COM (Walter Bright) (08/02/90)
In article <2353@laura.UUCP> bause@unido.uucp (Falko Bause) writes:
<A friend of mine is using Zortech 2.0. He uses hashed search tables and
<binary tree search tables. After some insertions into both tables he gets
<the error message: heap corrupted.
<Is this is known error of Zortech's C++?
<Please answer by e-mail to bause@unido.uucp
The "heap is corrupted" message is generated by the free() function under
the following conditions:
o An odd pointer is passed to free().
o A pointer is passed to free() that was not returned by malloc(),
calloc() or realloc().
o A pointer is free'd more than once.
o A wild pointer has trashed the free list data structure.
A common source of this error in C++ programs is when the compiler generates
a default copy constructor, and the objects contain pointers to malloc'd
data. (It's not a compiler bug!)jim.nutt@f30.n114.z1.fidonet.org (jim nutt) (08/02/90)
In a message of <Aug 02 12:22> ??? Bause ??? (1:114/15@fidonet) writes:
?B?> A friend of mine is using Zortech 2.0. He uses hashed search tables
?B?> and
?B?> binary tree search tables. After some insertions into both tables he
?B?> gets
?B?> the error message: heap corrupted.
?B?> Is this is known error of Zortech's C++?
it's a known error in your friend's code <grin>. heap corrupted means that
the heap free list got confused somehow... this can happen any number of ways,
of which my favorite is free()ing the same piece of memory twice... or better
yet, free()ing (or disposing) a variable that wasn't dynamically allocated in
the first place..
jim nutt
'the computer handyman'
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!30!jim.nutt
Internet: jim.nutt@f30.n114.z1.fidonet.orgBob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (08/02/90)
In a message of <Aug 01 09:48>, ??? Bause ??? writes: >A friend of mine is using Zortech 2.0. He uses hashed search tables and >binary tree search tables. After some insertions into both tables he gets > >the error message: heap corrupted. > >Is this is known error of Zortech's C++? This is a catch-all message ZTC++ prints when it encounters an illegal pointer operation such as free'ing memory which wasn't malloc'ed, etc. Have your friend check his code.
jaa@hutcs.hut.fi (Jari Alasuvanto) (08/03/90)
In article <2605@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes: > >The "heap is corrupted" message is generated by the free() function under >the following conditions: <A list of conditions deleted> >A common source of this error in C++ programs is when the compiler generates >a default copy constructor, and the objects contain pointers to malloc'd >data. (It's not a compiler bug!) I would add one common one to the list: a bug in your code using strings (applies to C as well): void causeError( const char* aString) { char* tmp = new char[ strlen(aString) ] ; // OOPS, forgot to add one for // terminating null strcpy ( tmp, aString ) ; } Errors of this kind will most likely go unnoticed for Motorola based machines and SPARCs, but with Intel-based architecture, the heap gets corrupted. This is due to different byte ordering. Check your code first before the compiler. -- Jari Alasuvanto, Lab. of Info Proc. Sci, Helsinki Univ. of Techology, Finland Internet: jaa@hutcs.hut.fi tel: +358-0-451 3236 fax: +358-0-465 077 <All the statements are my own -- HUT can make its own>>
sfo@sclcig.uucp (Steve) (08/03/90)
The Zortech heap manager puts some sanity check information in each block allocated by malloc()/calloc(). Each time you allocate or free memory, the heap manager check to see if this information has been modified. If so, then you get the heap corrupted message. In my case, I allocated space for a string and forgot to allocate space for the NUL byte. You may want to look for something similar. Note that the code corrupting the heap may be unrelated to the code that manipulates the heap.
bright@Data-IO.COM (Walter Bright) (08/07/90)
< A friend of mine is using Zortech 2.0. He uses hashed search tables and
< binary tree search tables. After some insertions into both tables he
< gets the error message: heap corrupted.
< Is this is known error of Zortech's C++?
Try this program with your favorite C compiler:
#include <stdlib.h>
main()
{ char *p;
p = (char *) malloc(10);
free(p);
free(p);
}
With Zortech, you'll get a "Heap is corrupted" message on the second free.
With some other compilers, you'll get silence, but this does not mean
that the program worked.roger@zuken.co.jp (Roger Meunier) (08/09/90)
In article <2613@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes: >Try this program with your favorite C compiler: > > #include <stdlib.h> > main() > { char *p; > p = (char *) malloc(10); > free(p); > free(p); > } > >With Zortech, you'll get a "Heap is corrupted" message on the second free. >With some other compilers, you'll get silence, but this does not mean >that the program worked. There should be a clear distinction in your comments as to what the compiler does and what the *run-time library* does. In your example, it's not clear if the compiler catches the second free or if the library routine does. -- Roger Meunier @ Zuken, Inc. Yokohama, Japan (roger@zuken.co.jp)
bright@Data-IO.COM (Walter Bright) (08/11/90)
In article <ROGER.90Aug9091458@rd11.zuken.co.jp> roger@zuken.co.jp (Roger Meunier) writes: <In article <2613@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes: < <Try this program with your favorite C compiler: < < #include <stdlib.h> < < main() < < { char *p; < < p = (char *) malloc(10); < < free(p); < < free(p); < < } < <With Zortech, you'll get a "Heap is corrupted" message on the second free. < <With some other compilers, you'll get silence, but this does not mean < <that the program worked. <There should be a clear distinction in your comments as to what the <compiler does and what the *run-time library* does. In your example, <it's not clear if the compiler catches the second free or if the library <routine does. The library does this. The compiler knows nothing about malloc or free.