Front page | perl.perl5.porters |
Postings from June 2003
Re: your malloc patches
Thread Previous
|
Thread Next
From:
Ilya Zakharevich
Date:
June 20, 2003 03:16
Subject:
Re: your malloc patches
Message ID:
20030620101551.GA1046@math.berkeley.edu
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
bytes).
Thanks,
Ilya
Thread Previous
|
Thread Next