Mail Archives: djgpp/1995/08/16/03:16:33
> I realize that the cause is likely that virtual store is handled in `pages'
>of fixed length, and that likely the heap gets to contain a random mixture of
>pieces of allocated live store and pieces of freed store which haven't been
>reallocated yet.
> Is this a common occurrence? How big are the `pages'? How do other users
>tend to solve this problem?
There are two versions of malloc floating around in the DJGPP stuff.
Maybe try the other one. One is claims to be optimised for C++ and
the other is an ordinary C version. I think the default one is the
ordinary C version.
After I had a small contretemps with malloc awhile back, the replies
suggested various debug versions of malloc. Alas, my internet
connection temporarily upped and died, so I took the idea and wrote
my own "Paranoid's mALLOC". Palloc is as bullet proof and paranoid as
I could make it. I check everything I could think of. And a couple of
others. Free'ing freed blocks. Writing to freed blocks. Not writing
to allocated blocks. Overwriting either bounds of blocks. etc. etc.
You can also set your level of paranoia and verbosity. It is also
easier to analyse exactly what the block size usage patterns are.
After useing palloc, you can be quite sure whether you have a memory
funny or not. If you interested I will email you the source.
John Carter
Institute for Water Quality Studies. Department of Water Affairs.
Internet : ece AT dwaf-hri DOT pwv DOT gov DOT za
Phone : 27-12-808-0374x194 Fax : 27-12-808-0338
"Lest we forget..."
The First World war ended at 11am on the 11th of November 1918. The
victors wrote the history books and laid the blame wholly on the
Germans. Later more scholarly and less propagandist books, such as
"The origins of the World War" by S.B. Fay apportion the blame on all
sides, notably on the French, who afterwards played the martyred
victim... And who are now playing with Nuclear weapons....
- Raw text -