|
From: Wuweijia <wuw...@hu...> - 2018-04-04 12:43:02
|
HI
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_Z_LIBC_SONAME, strcmp)",
Valgrind 3.12.
CPU:arm
The source as below:
#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
_Atomic(unsigned int ) g_status;
int main(int argc __unused , char ** argv __unused ) {
unsigned int init = 1;
int flag = 1;
unsigned int expect = random();
unsigned int value = 2;
atomic_init(&g_status, init);
if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
value, memory_order_acquire, memory_order_relaxed))) {
flag = 0;
}
printf("Done flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") ); ---------this line is number 27
return 1;
}
Valgrind show me output :
==30141== Invalid write of size 4
==30141== at 0x4C27CAE: strcat (strcmp.c:3)
==30141== by 0x108871: main (testClang.c:27)
==30141== Address 0xfeb445bc is on thread 1's stack
==30141== 12 bytes below stack pointer
BR
Owen
|
|
From: John R. <jr...@bi...> - 2018-04-05 04:17:04
|
> 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_Z_LIBC_SONAME, strcmp)”,
>
> Valgrind 3.12.
> CPU:arm
#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
_Atomic(unsigned int ) g_status;
#define __unused /*empty*/
#define __predict_true /*empty*/
int main(int argc __unused , char ** argv __unused ) {
unsigned int init = 1;
int flag = 1;
unsigned int expect = random();
unsigned int value = 2;
atomic_init(&g_status, init);
if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
value, memory_order_acquire, memory_order_relaxed))) {
flag = 0;
}
printf("Done flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") );
return 1;
}
The compiler name and version were not specified. I used:
gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
As shown, I had to #define the symbols __unused and __predict_true.
> Valgrind show me output :
> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3)
> ==30141== by 0x108871: main (testClang.c:27)
> ==30141== Address 0xfeb445bc is on thread 1's stack
> ==30141== 12 bytes below stack pointer
Using valgrind-3.13 on Fedora 28 beta for armv7l (armhfp; 32-bit ARM):
$ valgrind ./predict
==2012== Memcheck, a memory error detector
==2012== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2012== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2012== Command: ./predict
==2012==
Done flag:1 cmp:-1
==2012==
==2012== HEAP SUMMARY:
==2012== in use at exit: 0 bytes in 0 blocks
==2012== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==2012==
==2012== All heap blocks were freed -- no leaks are possible
==2012==
==2012== For counts of detected and suppressed errors, rerun with: -v
==2012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
|
|
From: John R. <jr...@bi...> - 2018-04-05 04:31:57
|
> printf("Done flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") ); ---------this line is number 27
> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3)
> ==30141== by 0x108871: main (testClang.c:27)
> ==30141== Address 0xfeb445bc is on thread 1's stack
> ==30141== 12 bytes below stack pointer
Show us the generated code for the printf statement:
(gdb) disassemble main
then copy+paste everything from the code for "flag = 0;"
to the code for "return 1;"
|
|
From: Wuweijia <wuw...@hu...> - 2018-04-11 03:32:43
|
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== 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<IRPCParam>::~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<android::sp<android::IVPBuffer> >::prep() (List.h:294)
==23233== by 0x53130D3: android::List<android::sp<android::IVPBuffer> >::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:
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()
4490: f94003e8 ldr x8, [sp]
4494: f9000500 str x0, [x8,#8]
system/core/libutils/include/utils/List.h:295
4498: f9400500 ldr x0, [x8,#8]
449c: f9400501 ldr x1, [x8,#8]
44a0: 9400002a bl 4548 <android::List<android::sp<android::IVPBuffer> >::_Node::setPrev(android::List<android::sp<android::IVPBuffer> >::_Node*)>
system/core/libutils/include/utils/List.h:296
44a4: f94003e8 ldr x8, [sp]
44a8: f9400500 ldr x0, [x8,#8]
44ac: f9400501 ldr x1, [x8,#8]
44b0: 9400002e bl 4568 <android::List<android::sp<android::IVPBuffer> >::_Node::setNext(android::List<android::sp<android::IVPBuffer> >::_Node*)>
system/core/libutils/include/utils/List.h:297
44b4: a9417bfd ldp x29, x30, [sp,#16]
44b8: 910083ff add sp, sp, #0x20
44bc: d65f03c0 ret
BR
Owen
-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2018年4月5日 12:17
收件人: 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?
> 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_Z_LIBC_SONAME, strcmp)”,
>
> Valgrind 3.12.
> CPU:arm
#include <errno.h>
#include <limits.h>
#include <stdatomic.h>
#include <string.h>
#include <sys/cdefs.h>
#include <sys/mman.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
_Atomic(unsigned int ) g_status;
#define __unused /*empty*/
#define __predict_true /*empty*/
int main(int argc __unused , char ** argv __unused ) {
unsigned int init = 1;
int flag = 1;
unsigned int expect = random();
unsigned int value = 2;
atomic_init(&g_status, init);
if (__predict_true(atomic_compare_exchange_strong_explicit(&g_status, &expect,
value, memory_order_acquire, memory_order_relaxed))) {
flag = 0;
}
printf("Done flag:%d cmp:%d \n", flag, strcmp("aaaa", "cccc") );
return 1;
}
The compiler name and version were not specified. I used:
gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20) As shown, I had to #define the symbols __unused and __predict_true.
> Valgrind show me output :
> ==30141== Invalid write of size 4
> ==30141== at 0x4C27CAE: strcat(strcmp.c:3) ==30141== by 0x108871:
> main (testClang.c:27) ==30141== Address 0xfeb445bc is on thread 1's
> stack ==30141== 12 bytes below stack pointer
Using valgrind-3.13 on Fedora 28 beta for armv7l (armhfp; 32-bit ARM):
$ valgrind ./predict
==2012== Memcheck, a memory error detector ==2012== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2012== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2012== Command: ./predict ==2012== Done flag:1 cmp:-1 ==2012== ==2012== HEAP SUMMARY:
==2012== in use at exit: 0 bytes in 0 blocks
==2012== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==2012==
==2012== All heap blocks were freed -- no leaks are possible ==2012== ==2012== For counts of detected and suppressed errors, rerun with: -v ==2012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
------------------------------------------------------------------------------
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
|
|
From: John R. <jr...@bi...> - 2018-04-11 20:22:48
|
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.
|
|
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
|
|
From: John R. <jr...@bi...> - 2018-04-13 00:38:10
|
> #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;
> }
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.
|
|
From: John R. <jr...@bi...> - 2018-04-12 23:27:29
|
> #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.
|
|
From: Wuweijia <wuw...@hu...> - 2018-04-13 03:25:27
|
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: 000000000005cd20 44 FUNC WEAK DEFAULT 12 _ZnamRKSt9nothrow_t
746: 000000000005ce34 4 FUNC WEAK DEFAULT 12 _ZnamSt11align_val_t
1793: 000000000005ce38 44 FUNC WEAK DEFAULT 12 _ZnamSt11align_val_tRKSt9
2089: 000000000005cd1c 4 FUNC WEAK DEFAULT 12 _Znam
4468: 000000000005cd1c 4 FUNC WEAK DEFAULT 12 _Znam
4778: 000000000005cd20 44 FUNC WEAK DEFAULT 12 _ZnamRKSt9nothrow_t
4779: 000000000005ce34 4 FUNC WEAK DEFAULT 12 _ZnamSt11align_val_t
4780: 000000000005ce38 44 FUNC WEAK 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:jr...@bi...]
发送时间: 2018年4月13日 7:27
收件人: val...@li...
主题: [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 <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.
------------------------------------------------------------------------------
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
|