Re: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?

[John R. <jr...@bi...>]

On 04/10/2018 08:32 PM, Wuweijia wrote:
> Hi John：
> 	I follow your instruction that upgrade the valgrind  from 3.12 to 3.13.   It seem to be okay, Thank you. I did not find any change in the vg_preload.c vg_redir.c .  Can you tell me why the error  do not occur.
> 
> 	But there is some mistake, I  still need to find out why.
> 	
> 	I run the aarch64 Application, with valgrind 3.13..
> 	It show me this error:
> ==23233== Mismatched free() / delete / delete []
> ==23233==    at 0x582144C: operator delete[](void*) (vg_replace_malloc.c:620)
> ==23233==    by 0x531351B: android::List<android::sp<android::IVPBuffer> >::~List() (List.h:174)

> ==23233==  Address 0x4ae91c0 is 0 bytes inside a block of size 24 alloc'd
> ==23233==    at 0x582082C: operator new(unsigned long) (vg_replace_malloc.c:333)----------------show me  I call new() function  not new[]
> ==23233==    by 0x531349F: android::List<android::sp<android::IVPBuffer> >::prep() (List.h:294)

> And then I objdump the so , the machine code show me as below:
>   000000000000446c <android::List<android::sp<android::IVPBuffer> >::prep()>:
> _ZN7android4ListINS_2spINS_9IVPBufferEEEE4prepEv():
> system/core/libutils/include/utils/List.h:293
>      446c:	d10083ff 	sub	sp, sp, #0x20
>      4470:	a9017bfd 	stp	x29, x30, [sp,#16]
>      4474:	910043fd 	add	x29, sp, #0x10
>      4478:	b27d07e8 	orr	x8, xzr, #0x18
>      447c:	f90007e0 	str	x0, [sp,#8]
>      4480:	f94007e0 	ldr	x0, [sp,#8]
> system/core/libutils/include/utils/List.h:294
>      4484:	f90003e0 	str	x0, [sp]
>      4488:	aa0803e0 	mov	x0, x8
>      448c:	97fffb8b 	bl	32b8 <operator new[](unsigned long)@plt> -------------------It show me I used the new[] function not the new(),but valgrind show me I used the new()

Now we need to see the details of the redirections that valgrind performs:
intercepting calls to 'operator new' and 'operator new[]',
and calling their replacements in vg_replace_malloc.c instead.

Please run
    valgrind -v ./my_app
and report the  REDIR  lines, such as:
    --9315-- REDIR: 0x4ec9b40 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x4c2e87b (operator new[](unsigned long))
We want to see if both 'operator new' and 'operator new[]' are intercepted separately.

Also, please show the difference between the address of the 'operator new' subroutine
and the address of the 'operator new[]' subroutine.  There may be low-level optimizations
where 'operator new[]' tail merges into 'opeartor new' such that it is difficult
to track the difference.