[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
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 >::~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 >::prep() (List.h:294) And then I objdump the so , the machine code show me as below: 446c >::prep()>: _ZN7android4ListINS_2spINS_9IVPBuffer4prepEv(): system/core/libutils/include/utils/List.h:293 446c: d10083ffsub sp, sp, #0x20 4470: a9017bfdstp x29, x30, [sp,#16] 4474: 910043fdadd x29, sp, #0x10 4478: b27d07e8orr x8, xzr, #0x18 447c: f90007e0str x0, [sp,#8] 4480: f94007e0ldr x0, [sp,#8] system/core/libutils/include/utils/List.h:294 4484: f90003e0str x0, [sp] 4488: aa0803e0mov x0, x8 448c: 97fffb8bbl 32b8 ---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
[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 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 >::~List() (List.h:174) ==23233==by 0x5313233: RPCParcel::~RPCParcel() (RPCParcel.h:166) ==23233==by 0x5313273: RPCParcel::~RPCParcel() (RPCParcel.h:162) ==23233==by 0x9DCFA2F: android::RefBase::decStrong(void const*) const (RefBase.cpp:434) ==23233==by 0x5312E8B: android::sp::~sp() (StrongPointer.h:157) ==23233==by 0x53127E7: test_xvAlloc_proxy(char*, int) (test7.cpp:21) ==23233==by 0x5313037: processAlgo (test7.cpp:45) ==23233==by 0x55B1CAB: android::PPAlgorithmEngine::processAlgo(void*, int, android::imageBufInfos*) (PPAlgorithmEngine.cpp:237) ==23233==by 0xA3561D7: Call(void*, unsigned int, double*) (ivptest.cpp:166) ==23233==by 0x11D00B: CHECK_STUB_IVP_ALLOCDualTile_Test::TestBody() (testIT_xvAlloc.cpp:27) ==23233==by 0x14BEDF: testing::Test::Run() (gtest.cc:0) ==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 >::prep() (List.h:294) ==23233==by 0x53130D3: android::List >::List() (List.h:166) ==23233==by 0x531285F: RPCParcel::RPCParcel() (RPCParcel.h:146) ==23233==by 0x53126EB: test_xvAlloc_proxy(char*, int) (test7.cpp:10) ==23233==by 0x5313037: processAlgo (test7.cpp:45) ==23233==by 0x55B1CAB: android::PPAlgorithmEngine::processAlgo(void*, int, android::imageBufInfos*) (PPAlgorithmEngine.cpp:237) ==23233==by 0xA3561D7: Call(void*, unsigned int, double*) (ivptest.cpp:166) ==23233==by 0x11D00B: CHECK_STUB_IVP_ALLOCDualTile_Test::TestBody() (testIT_xvAlloc.cpp:27) ==23233==by 0x14BEDF: testing::Test::Run() (gtest.cc:0) ==23233==by 0x14C9EB: testing::TestInfo::Run() (gtest.cc:2655) ==23233==by 0x14CE57: testing::TestCase::Run() (gtest.cc:2773) And then I objdump the so , the machine code show me as below: 446c >::prep()>: _ZN7android4ListINS_2spINS_9IVPBuffer4prepEv(): system/core/libutils/include/utils/List.h:293 446c: d10083ffsub sp, sp, #0x20 4470: a9017bfdstp x29, x30, [sp,#16] 4474: 910043fdadd x29, sp, #0x10 4478: b27d07e8orr x8, xzr, #0x18 447c: f90007e0str x0, [sp,#8] 4480: f94007e0ldr x0, [sp,#8] system/core/libutils/include/utils/List.h:294 4484: f90003e0str x0, [sp] 4488: aa0803e0mov x0, x8 448c: 97fffb8bbl 32b8 ---It show me I used the new[] function not the new(),but valgrind show me I used the new() 4490: f94003e8ldr x8, [sp] 4494: f9000500str x0, [x8,#8] system/core/libutils/include/utils/List.h:295 4498: f9400500ldr x0, [x8,#8] 449c: f9400501ldr x1, [x8,#8] 44a0: 942abl 4548 >::_Node::setPrev(android::List >::_Node*)> system/core/libutils/include/utils/List.h:296 44a4: f94003e8ldr x8, [sp] 44a8: f9400500ldr x0, [x8,#8] 44ac: f9400501ldr x1, [x8,#8] 44b0: 942ebl 4568 >::_Node::setNext(android::List >::_Node*)> system/core/libutils/include/utils/List.h:297 44b4: a9417bfdldp x29, x30, [sp,#16] 44b8: 910083ffadd sp, sp, #0x20 44bc: d65f03c0ret BR Owen -邮件原件- 发件人: John Reiser [mailto:jrei...@bitwagon.com] 发送时间: 2018年4月5日 12:17 收件人: 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? > Why I call the strcmp, but function stack show that the > strcat is called not the strcmp, but the file is belong to the > function strcmp > Can you show the how to replace the strcmp with > “STRCMP(VG_Z_LIBC_SONAME, strcmp)”, and then I can follow the code > to find out why. > > I can find the code you set the LD_PRELOAD , but symbol name > is not match, I do not know how you replace the strcmp with > STRCMP(VG_Z_LIBC_SONAME, strcmp). > Can you help to point out the function do the job > replace the strcmp with STRCMP(VG_
