[Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?
Hi John
You mean I need hide to the symbal operator new in libc.so ?
So I trip the libc.so , so there is no symbals operator new in libc.so
localhost:/system/bin # readelf -s ../lib64/libc++.so | grep Znam
696: 0005cd2044 FUNCWEAK DEFAULT 12 _ZnamRKSt9nothrow_t
746: 0005ce34 4 FUNCWEAK DEFAULT 12 _ZnamSt11align_val_t
1793: 0005ce3844 FUNCWEAK DEFAULT 12
_ZnamSt11align_val_tRKSt9
2089: 0005cd1c 4 FUNCWEAK DEFAULT 12 _Znam
4468: 0005cd1c 4 FUNCWEAK DEFAULT 12 _Znam
4778: 0005cd2044 FUNCWEAK DEFAULT 12 _ZnamRKSt9nothrow_t
4779: 0005ce34 4 FUNCWEAK DEFAULT 12 _ZnamSt11align_val_t
4780: 0005ce3844 FUNCWEAK DEFAULT 12
_ZnamSt11align_val_tRKSt9
localhost:/system/bin # readelf -s ../lib64/libc.so | grep Znam
So I re-run it , there is no printf for "REDIR to operator new " or "
malloc";
--9071-- REDIR: 0x4b23130 (libc.so:memset) redirected to 0x4c8b2b4 (memset)
--9071-- REDIR: 0x4b6a580 (libc.so:__memcpy_chk) redirected to 0x4c8ba1c
(__memcpy_chk)
--9071-- REDIR: 0x4b1fcec (libc.so:malloc) redirected to 0x4c8c168 (malloc)
--9071-- REDIR: 0x4b23710 (libc.so:strlen) redirected to 0x4c8a75c (strlen)
--9071-- REDIR: 0x4b6a514 (libc.so:__strcpy_chk) redirected to 0x4c8b7ac
(__strcpy_chk)
--9071-- REDIR: 0x4b2389c (libc.so:strncmp) redirected to 0x4c8a988 (strncmp)
--9071-- REDIR: 0x4b22c70 (libc.so:memcpy) redirected to 0x4c8adc8 (memcpy)
--9071-- REDIR: 0x4b22ab4 (libc.so:memchr) redirected to 0x4c8ab94 (memchr)
--9071-- REDIR: 0x4b1ff38 (libc.so:realloc) redirected to 0x4c8d734 (realloc)
--9071-- REDIR: 0x4b1fbac (libc.so:free) redirected to 0x4c8cdac (free)
--9071-- REDIR: 0x4b22bc0 (libc.so:memcmp) redirected to 0x4c8b02c (bcmp)
--9071-- REDIR: 0x4b23540 (libc.so:strcmp) redirected to 0x4c8ab54 (strcmp)
--9071-- REDIR: 0x4ba8620 (libc.so:strstr) redirected to 0x4c8bbe8 (strstr)
no=0x4ea4d20 n1=0x4ea4d70
--9071-- REDIR: 0x4d03a60 (libc++.so:operator delete[](void*)) redirected to
0x4c8d3c4 (operator delete[](void*))
==9071== Mismatched free() / delete / delete []
==9071==at 0x4C8D44C: operator delete[](void*) (vg_replace_malloc.c:620)
==9071==by 0x108797: demoNew (testNew.cpp:16)
==9071==by 0x108797: main (testNew.cpp:21)
==9071== Address 0x4ea4d70 is 0 bytes inside a block of size 8 alloc'd
==9071==at 0x4C8C1F0: malloc (vg_replace_malloc.c:298)
==9071==by 0x4D15CAF: operator new(unsigned long) (stdlib_new_delete.cpp:33)
==9071==by 0x10876F: demoNew (testNew.cpp:13)
==9071==by 0x10876F: main (testNew.cpp:21)
Libc++.so is llvm c++, not gnu c++;
Br
Owen
-邮件原件-
发件人: John Reiser [mailto:jrei...@bitwagon.com]
发送时间: 2018年4月13日 7:27
收件人: valgrind-users@lists.sourceforge.net
主题: [Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android
version(arm32), I am confused by function stack. Can you show me why?
> #include
> #include
>
> 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
> 000b2924 t operator new[](unsigned long)
> 000b28d8 t
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?
#include
#include
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;
}
For reference and comparison, on x86_64 Linux with
g++ (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
libstdc++-6.4.1-1.fc25.x86_64
the relevant interceptions are
--13225-- REDIR: 0x4ec9a80 (libstdc++.so.6:operator new(unsigned long))
redirected to 0x4c2e18e (operator new(unsigned long))
--13225-- REDIR: 0x4ec9b40 (libstdc++.so.6:operator new[](unsigned long))
redirected to 0x4c2e87b (operator new[](unsigned long))
--13225-- REDIR: 0x4ec7a70 (libstdc++.so.6:operator delete(void*)) redirected
to 0x4c2f1ac (operator delete(void*))
--13225-- REDIR: 0x4ec7aa0 (libstdc++.so.6:operator delete[](void*)) redirected
to 0x4c2f67c (operator delete[](void*))
and valgrind does not complain about anything.
--
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
[Valgrind-users] 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?
#include
#include
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
000b2924 t operator new[](unsigned long)
000b28d8 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
0005cd1c W operator new[](unsigned long)
0005cc8c 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.
--
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
[Valgrind-users] Introducing valgrind-preload project
Hi all, I wanted to share a link to my project, Valgrind-preload (https://github.com/yugr/valgrind-preload) to hopefully get some comments, suggestions or bugreports. Valgrind-preload is a simple LD_PRELOAD-able library which will cause all spawned processes to be started under Valgrind. It's functionality is similar to Valgrind's standard --trace-children=yes but fixes few issues: * avoids instrumenting setuid processes (Valgrind can't handle them so you have to laboriously blacklist all of them via --trace-children-skip which is unreliable and disables instrumentation of grandchildren) * can easily be enabled for the whole distro or chroot via ld.so.preload (as there's no need to search for init and replace it with custom wrapper) The tool seems to be pretty stable now, e.g. I was able to instrument complete Debian package builds and even found several new bugs (listed on main page). You can check the link above for additional details. Thanks, Yury Gribov -- 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
[Valgrind-users] 答复: 答复: [HELP] I run the valgrind in the unreleased android version(arm32), I am confused by function stack. Can you show me why?
Hi John:
I wrote the simple example， error can re-producce.
As below:
#include
#include
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
#include
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
000259c8 t prop_area::new_prop_bt(char const*, unsigned int, unsigned
int*)
00025b18 t prop_area::new_prop_info(char const*, unsigned int, char
const*, unsigned int, unsigned int*)
000b2924 t operator new[](unsigned long)
000b28d8 t operator new(unsigned long)
000d0468 t je_arena_new
000de260 t je_extent_tree_ad_new
000dd78c t je_extent_tree_szsnad_new
000ea038 t je_rtree_new
00035004 T newlocale
0007f16c t nonnewline
localhost:/system/bin # nm -C ../lib64/libc++.so | grep new
0005cd1c W operator new[](unsigned long)
0005cd20 W operator new[](unsigned long, std::nothrow_t const&)
0005ce34 W operator new[](unsigned long, std::align_val_t)
0005ce38 W operator new[](unsigned long, std::align_val_t,
std::nothrow_t const&)
0005cc8c W operator new(unsigned long)
0005ccf0 W operator new(unsigned long, std::nothrow_t const&)
0005cd5c W operator new(unsigned long, std::align_val_t)
0005ce08 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/
