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:jrei...@bitwagon.com] 
发送时间: 2018年4月12日 4:23
收件人: valgrind-users@lists.sourceforge.net
主题: 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to