Marcus Holland-Moritz wrote:
>On 2004-09-28, at 17:00:16 +0100, Steve Hay wrote:
>
>
>
>>What does "chunk's tail overwrite" overwrite mean?
>>
>>It comes from malloc.c line 2074 (perl-5.8.5). An XS module of mine
>>keeps crashing with the message:
>>
>>assertion botched (chunk's tail overwrite?): ((unsigned int
>>*)((caddr_t)ovp + nbytes))[-1] == 0x55555555 (..\malloc.c:2074)
>>
>>when run under a DEBUGGING perl with perl's malloc. The software
>>apparently runs OK under a release-mode perl, and under perls with the
>>system malloc (both release and DEBUGGING), but I suspect that all is
>>not really well in light of the above.
>>
>>The Safefree() call is freeing up the SV's PV slot, which was earlier
>>assigned to the SV (and realloc()'ed) via sv_usepvn(). I haven't made
>>the mistake of attempting to free the space given to the SV as its PV
>>slot separately, so I'm at a loss as to what the problem is.
>>
>>Any ideas what this assertion failure might indicate?
>>
>>
>
>Without looking at the malloc code in detail, the assertion
>seems to indicate that the tail of an allocated memory block
>has been overwritten.
>
>Each block (chunk) is protected by a magic number (0x55555555)
>right before (head) and right after (tail) the block. At free
>time, both are checked to see if the block was overwritten in
>any direction.
>
So in other words, the magic number after the thing being freed (the
realloc()'ed PV slot) has been overwritten.
That suggested to me that I hadn't correctly told Perl what the length
of the SV's new PV slot was, and (embarassingly) that was indeed the
case :( The length I had given to sv_usepvn() was the sizeof() the
pointer (4 bytes on my system), instead of the sizeof() what it was
pointing at, something like this:
typedef struct {
int i;
int j;
int k;
} footype;
SV *sv;
footype *foo;
sv = NEWSV(0, 0);
New(0, foo, 1, footype);
sv_usepvn(sv, (char *)foo, sizeof foo);
foo->i = 1;
foo->j = 2;
foo->k = 3;
SvREFCNT_dec(sv); // asserts
The last arg to sv_usepvn() should have been sizeof(*foo) (12 bytes in
this case!).
So thanks for the helpful explanation -- it led me straight to the problem.
Catching bugs like this is one more reason to prefer (at the very least
testing with) Perl's malloc. As I said, the software was apparently
running OK with system malloc, even in debug mode. The problem would no
doubt have reared its ugly head sooner or later, and would have been
much harder to fix.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
