cgf@infinet.UUCP (Chris Faylor) (11/04/85)
{}
Has anyone out there noticed any problems with the realloc routine
distributed with Microsoft C? It seems to sometimes leave garbage
in the middle of a reallocated block of memory if the newly malloc'ed
block overlaps the old.
Looking at the code, it seems pretty obvious that there will be times
when this will definitely happen. It will always fail if you try
to increase the size of a block from, say, 10 bytes to 16 bytes, and
there are 6 free bytes immediately preceding the original ten.
What happens is that realloc first frees the block it is trying to
expand, then malloc sets aside the only available 16 bytes, placing
a memory size header in the middle of the original 10 byte block.
Then realloc copies the old block, header and all, up 6 bytes.
In general, it seems that malloc does not behave well if you have
the misfortune of running out of memory. I have not completely
corroborated it, but it looks like a pointer somewhere gets
screwed up. After returning a NULL (indicating that there isn't
enough contiguous memory for the request) it appears that it will
sometimes start allocating new memory over previously allocated blocks.
Anybody else seen this?
--
-cgf-
I feel more like I do now than I did when I first got here.
decvax!wanginst!infinet!cgf
emacs!infinet!cgf@cca-unix.ARPApapke@dicomed.UUCP (Kurt Papke) (11/14/85)
In article <279@infinet.UUCP> cgf@infinet.UUCP (Chris Faylor) writes: >{} >Has anyone out there noticed any problems with the realloc routine >distributed with Microsoft C? It seems to sometimes leave garbage >in the middle of a reallocated block of memory if the newly malloc'ed >block overlaps the old. I have used the realloc() routine quite a bit and have never experienced the problem you describe. >Looking at the code, it seems pretty obvious that there will be times >when this will definitely happen. It will always fail if you try >to increase the size of a block from, say, 10 bytes to 16 bytes, and >there are 6 free bytes immediately preceding the original ten. >What happens is that realloc first frees the block it is trying to >expand, then malloc sets aside the only available 16 bytes, placing >a memory size header in the middle of the original 10 byte block. >Then realloc copies the old block, header and all, up 6 bytes. Could be. How do you know this without the sources to the run-time library ?? >In general, it seems that malloc does not behave well if you have >the misfortune of running out of memory. I have not completely >corroborated it, but it looks like a pointer somewhere gets >screwed up. After returning a NULL (indicating that there isn't >enough contiguous memory for the request) it appears that it will >sometimes start allocating new memory over previously allocated blocks. >Anybody else seen this? No, although most of the code I've written with 3.0 has no choice but to roll over and die when it runs out of heap !!
cgf@infinet.UUCP (Chris Faylor) (11/19/85)
In article <649@dicomed.UUCP> papke@dicomed.UUCP (Kurt Papke) replies: > ... >I have used the realloc() routine quite a bit and have never experienced >the problem you describe. > >>Looking at the code, it seems pretty obvious that there will be times >>when this will definitely happen. It will always fail if you try >>to increase the size of a block from, say, 10 bytes to 16 bytes, and >>there are 6 free bytes immediately preceding the original ten. >>What happens is that realloc first frees the block it is trying to >>expand, then malloc sets aside the only available 16 bytes, placing >>a memory size header in the middle of the original 10 byte block. >>Then realloc copies the old block, header and all, up 6 bytes. > >Could be. How do you know this without the sources to the run-time >library ?? Excuse me. I should have said "disassembled listing" instead of "code". >No, although most of the code I've written with 3.0 has no choice but >to roll over and die when it runs out of heap !! I guess I just like to live in the fast lane. My application attempts to do some cleanup and recovery when it runs out of heap !! I have received mail which indicates that these bugs existed in UNIX Version 7 malloc and in XENIX and VENIX. So I suppose there is a real good possibility that Microsoft ported the bugs to MSDOS, too. -- -cgf- I feel more like I do now than I did when I first got here. decvax!wanginst!infinet!cgf emacs!infinet!cgf@cca-unix.ARPA