Menu
▾
▴
[Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?
|
From: Wuweijia <wuw...@hu...> - 2018-04-12 09:11:17
|
Hi John:
I wrote the simple example， error can re-producce.
As below:
#include <stdio.h>
#include <stdlib.h>
class Node{
public:
int a;
int b;
};
extern "C" void demoNew(void) {
Node *n0 = new Node;
Node *n1 = (Node *)new char[sizeof(Node)];
printf("no=%p n1=%p\n", n0, n1);
delete n0;
delete[] n1;
}
int main(int argc, char ** argv) {
demoNew();
return 0;
} #include <stdio.h>
#include <stdlib.h>
class Node{
public:
int a;
int b;
};
extern "C" void demoNew(void) {
Node *n0 = new Node;
Node *n1 = (Node *)new char[sizeof(Node)];
printf("no=%p n1=%p\n", n0, n1);
delete n0;
delete[] n1; -----------------------------------------this is line 15
}
int main(int argc, char ** argv) {
demoNew();
return 0;
}
libc.so:operator new and (libc.so:operator new[] are separated.
--4747-- Reading syms from /system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so
linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_P_EA1/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
--4747-- REDIR: 0x4d0a130 (libc.so:memset) redirected to 0x4c1a2b4 (memset)
--4747-- REDIR: 0x4d51580 (libc.so:__memcpy_chk) redirected to 0x4c1aa1c (__memcpy_chk)
--4747-- REDIR: 0x4d06cec (libc.so:malloc) redirected to 0x4c1b168 (malloc)
--4747-- REDIR: 0x4d0a710 (libc.so:strlen) redirected to 0x4c1975c (strlen)
--4747-- REDIR: 0x4d51514 (libc.so:__strcpy_chk) redirected to 0x4c1a7ac (__strcpy_chk)
--4747-- REDIR: 0x4d0a89c (libc.so:strncmp) redirected to 0x4c19988 (strncmp)
--4747-- REDIR: 0x4d09c70 (libc.so:memcpy) redirected to 0x4c19dc8 (memcpy)
--4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long)) redirected to 0x4c1bb48 (operator new[](unsigned long))
--4747-- REDIR: 0x4d09ab4 (libc.so:memchr) redirected to 0x4c19b94 (memchr)
--4747-- REDIR: 0x4d06f38 (libc.so:realloc) redirected to 0x4c1c734 (realloc)
--4747-- REDIR: 0x4d06bac (libc.so:free) redirected to 0x4c1bdac (free)
--4747-- REDIR: 0x4d09bc0 (libc.so:memcmp) redirected to 0x4c1a02c (bcmp)
--4747-- REDIR: 0x4d0a540 (libc.so:strcmp) redirected to 0x4c19b54 (strcmp)
--4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long)) redirected to 0x4c1b7a4 (operator new(unsigned long))
--4747-- REDIR: 0x4d8f620 (libc.so:strstr) redirected to 0x4c1abe8 (strstr)
no=0x4eb9d20 n1=0x4eb9d70
--4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*)) redirected to 0x4c1c3c4 (operator delete[](void*))
==4747== Mismatched free() / delete / delete []
==4747== at 0x4C1C44C: operator delete[](void*) (vg_replace_malloc.c:620)
==4747== by 0x108797: demoNew (testNew.cpp:15)
==4747== by 0x108797: main (testNew.cpp:20)
==4747== Address 0x4eb9d70 is 0 bytes inside a block of size 8 alloc'd
==4747== at 0x4C1B1F0: malloc (vg_replace_malloc.c:298)
==4747== by 0x4B56CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)
==4747== by 0x10876F: demoNew (testNew.cpp:12)
==4747== by 0x10876F: main (testNew.cpp:20)
localhost:/system/bin # nm -C ../lib64/libc.so | grep new
00000000000259c8 t prop_area::new_prop_bt(char const*, unsigned int, unsigned int*)
0000000000025b18 t prop_area::new_prop_info(char const*, unsigned int, char const*, unsigned int, unsigned int*)
00000000000b2924 t operator new[](unsigned long)
00000000000b28d8 t operator new(unsigned long)
00000000000d0468 t je_arena_new
00000000000de260 t je_extent_tree_ad_new
00000000000dd78c t je_extent_tree_szsnad_new
00000000000ea038 t je_rtree_new
0000000000035004 T newlocale
000000000007f16c t nonnewline
localhost:/system/bin # nm -C ../lib64/libc++.so | grep new
000000000005cd1c W operator new[](unsigned long)
000000000005cd20 W operator new[](unsigned long, std::nothrow_t const&)
000000000005ce34 W operator new[](unsigned long, std::align_val_t)
000000000005ce38 W operator new[](unsigned long, std::align_val_t, std::nothrow_t const&)
000000000005cc8c W operator new(unsigned long)
000000000005ccf0 W operator new(unsigned long, std::nothrow_t const&)
000000000005cd5c W operator new(unsigned long, std::align_val_t)
000000000005ce08 W operator new(unsigned long, std::align_val_t, std::nothrow_t const&)
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2018年4月12日 4:23
收件人: val...@li...
主题: 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?
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.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
