[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...>]

> #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;
> }

> --4747-- REDIR: 0x4d9b924 (libc.so:operator new[](unsigned long)) redirected to 0x4c1bb48 (operator new[](unsigned long))

> --4747-- REDIR: 0x4d9b8d8 (libc.so:operator new(unsigned long)) redirected to 0x4c1b7a4 (operator new(unsigned long))

Well, it is puzzling why 'operator new[]' and 'operator new' are in libc.so,
the run-time library for *plain*-C.  The C language does not have such functions.

> --4747-- REDIR: 0x4b44a60 (libc++.so:operator delete[](void*)) redirected to 0x4c1c3c4 (operator delete[](void*))

OK, that's the regular 'operator delete[]' for C++.
Where is 'operator delete', the non-array flavor?


> ==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)

That reference above to 'operator new(unsigned long)' should have been intercepted
directly by valgrind, instead of first calling malloc() [which was intercepted.]
Valgrind does not know about "stdlib_new_delete.cpp".  Which shared library is it in?

> ==4747==    by 0x10876F: demoNew (testNew.cpp:12)
> ==4747==    by 0x10876F: main (testNew.cpp:20)
> 
> localhost:/system/bin # nm -C  ../lib64/libc.so  | grep new

> 00000000000b2924 t operator new[](unsigned long)
> 00000000000b28d8 t operator new(unsigned long)

Again, I don't understand why libc.so has those functions.
Does it have also the corresponding 'delete' and 'delete[]'?

> 
> localhost:/system/bin # nm -C  ../lib64/libc++.so  | grep new
> 000000000005cd1c W operator new[](unsigned long)
> 000000000005cc8c W operator new(unsigned long)


My working hypothesis is that appearance in libc.so
of the code for some C++ operators, instead of appearing only in libc++.so,
has confused valgrind.  Also note that the C++ 'operator new'
is a 'W' (weak global) symbol, but the plain-C symbol 'operator new'
is a 't' (strong local) symbol.  A local symbol is not exported,
so it is visible only to calls from the same source file.
On the other hand, a weak symbol becomes hidden if there is
any [visible] strong definition.  This is very confusing.