|
From: Konstantin S. <kon...@gm...> - 2010-05-07 14:37:02
|
Hi,
The code in die_and_free_mem (memcheck/mc_malloc_wrappers.c) is:
/* Put it out of harm's way for a while, if not from a client request */
if (MC_AllocCustom != mc->allockind) {
/* Record where freed */
mc->where = VG_(record_ExeContext) ( tid, 0/*first_ip_delta*/ );
add_to_freed_queue ( mc );
} else {
VG_(free) ( mc );
}
So, if I allocate a chunk of memory, free it and then access, I get a
warning like this:
--------------------------------------------------------------------------------
Invalid read of size 4
<STACK>
Address 0xb00601f34 is 20 bytes inside a block of size 40 free'd
<STACK>
--------------------------------------------------------------------------------
If I have a custom allocator which is annotated
with VALGRIND_{MALLOCLIKE,FREELIKE}_BLOCK, I get a much less informative
report:
--------------------------------------------------------------------------------
Invalid read of size 4
<STACK>
Address 0xb00601f34 is not stack'd, malloc'd or (recently) free'd
--------------------------------------------------------------------------------
Why?
I get what I need If I change the code in die_and_free_mem to simply this:
mc->where = VG_(record_ExeContext) ( tid, 0/*first_ip_delta*/ );
add_to_freed_queue ( mc );
Is there a reason not to do this?
Thanks,
--kcc
|
|
From: Nicholas N. <n.n...@gm...> - 2010-05-12 01:58:33
|
On Fri, May 7, 2010 at 7:36 AM, Konstantin Serebryany
<kon...@gm...> wrote:
> Hi,
> The code in die_and_free_mem (memcheck/mc_malloc_wrappers.c) is:
> /* Put it out of harm's way for a while, if not from a client request */
> if (MC_AllocCustom != mc->allockind) {
> /* Record where freed */
> mc->where = VG_(record_ExeContext) ( tid, 0/*first_ip_delta*/ );
> add_to_freed_queue ( mc );
> } else {
> VG_(free) ( mc );
> }
> So, if I allocate a chunk of memory, free it and then access, I get a
> warning like this:
> --------------------------------------------------------------------------------
> Invalid read of size 4
> <STACK>
> Address 0xb00601f34 is 20 bytes inside a block of size 40 free'd
> <STACK>
> --------------------------------------------------------------------------------
> If I have a custom allocator which is annotated
> with VALGRIND_{MALLOCLIKE,FREELIKE}_BLOCK, I get a much less informative
> report:
> --------------------------------------------------------------------------------
> Invalid read of size 4
> <STACK>
> Address 0xb00601f34 is not stack'd, malloc'd or (recently) free'd
> --------------------------------------------------------------------------------
> Why?
> I get what I need If I change the code in die_and_free_mem to simply this:
> mc->where = VG_(record_ExeContext) ( tid, 0/*first_ip_delta*/ );
> add_to_freed_queue ( mc );
> Is there a reason not to do this?
That won't work because when it gets removed from the free list
Memcheck will try to free it with VG_(free) which won't work because
it's custom allocated.
However, I think add_to_freed_queue() could first check and call
VG_(free) only if it's not custom-allocated. Care to file a bug?
N
|
|
From: Julian S. <js...@ac...> - 2010-05-12 07:59:05
|
> However, I think add_to_freed_queue() could first check and call > VG_(free) only if it's not custom-allocated. Care to file a bug? Kostya, can you give it a try, see if that helps? Also, filing a bug to track this with would be good. I actually already grappled with this problem some weeks back, and I have a patch which "fixes" it, by keeping a journal of the last 16k AllocCustom blocks freed, and looking in that to get the required information if everything else fails. But it's inelegant (yet another data structure) and slow. I will put the patch on the bug report if you file one :-) J |
|
From: Konstantin S. <kon...@gm...> - 2010-05-12 11:23:32
|
On Wed, May 12, 2010 at 12:22 PM, Julian Seward <js...@ac...> wrote: > > > However, I think add_to_freed_queue() could first check and call > > VG_(free) only if it's not custom-allocated. Care to file a bug? > > Kostya, can you give it a try, see if that helps? On simple cases it seems to help. Filed a bug: https://bugs.kde.org/show_bug.cgi?id=237371 --kcc > Also, filing a bug > to track this with would be good. > > I actually already grappled with this problem some weeks back, and I > have a patch which "fixes" it, by keeping a journal of the last 16k > AllocCustom blocks freed, and looking in that to get the required > information if everything else fails. But it's inelegant (yet another > data structure) and slow. I will put the patch on the bug report if > you file one :-) > > J > |