develooper Front page | perl.perl5.porters | Postings from June 2003

Re: your malloc patches

Thread Previous | Thread Next
Ilya Zakharevich
June 20, 2003 03:16
Re: your malloc patches
Message ID:
On Fri, Jun 20, 2003 at 01:01:27PM +0300, Jarkko Hietaniemi wrote:
> > So if you disable bug-detection feature, things work.  ;-) So add
> Of course I find your belief in the buglessness of your own code
> admirable :-) but are you absolutely certain your new code works in
> sizeof(int)==4,sizeof(long)==8,sizeof(ptr)==MEM_ALIGNBYTES==8 world?
> (That's what Tru64 is.)

Well, you said you tested it on other 64bit stuff; and you said that
mymalloc was not working before anyway - so I presumed that we are
talking about fixing this situation.

So I was wrong.  Of course bugs are possible - and other 64bit
platforms could have had int=long=ptr=8.

> > Anyway, I was wrong that I can't do better with detection of
> > write-to-free()ed-or-not-yet-malloc()ed region (this is what happens
> > above).  But before I do this (some work required), could somebody
> > check what is the contents of memory when FILLCHECK_DEADBEEF() fails?
> I'll find out.

If it is really bugs in malloc.c, then it is the pair of
fill()/check() which is failing.  The test above would give some info
*which* one of these two steps fails.  The target is to have memory
0xDEADBEEF-filled (4-byte-aligned).  And if any malloc() was done with
this memory, it should have 4 0x55 bytes before the region, and >=4
0x55 bytes after the region (up to 4-byte aligned boundary; actually,
on 64-bit machines it may have been 0x55 0x55 0x55 0x55 0x00 0x00 0x00
0x00 or 0x00 0x00 0x00 0x00 0x55 0x55 0x55 0x55 instead of 4 0x55


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About