[Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

Wuweijia

 

The output as below:

 

localhost:/system/bin # LD_PRELOAD=/system/bin/linker64 ./valgrind --tool=massif -v  --pages-as-heap=yes  ./mcfPQ --gtest_filter=*DISTANCE_001_001*

==20333== Massif, a heap profiler

==20333== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote

==20333== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info

==20333== Command: ./mcfPQ --gtest_filter=*DISTANCE_001_001*

==20333==

--20333-- Valgrind options:

--20333--    --tool=massif

--20333--    -v

--20333--    --pages-as-heap=yes

--20333-- Contents of /proc/version:

--20333--   Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016

--20333--

--20333-- Arch and hwcaps: ARM64, LittleEndian, baseline

--20333-- Page sizes: currently 4096, max supported 65536

--20333-- Valgrind library directory: /system/lib64/valgrind

--20333-- Massif: alloc-fns:

--20333-- Massif:   malloc

--20333-- Massif:   __builtin_new

--20333-- Massif:   operator new(unsigned)

--20333-- Massif:   operator new(unsigned long)

--20333-- Massif:   __builtin_vec_new

--20333-- Massif:   operator new[](unsigned)

--20333-- Massif:   operator new[](unsigned long)

--20333-- Massif:   calloc

--20333-- Massif:   realloc

--20333-- Massif:   memalign

--20333-- Massif:   posix_memalign

--20333-- Massif:   valloc

--20333-- Massif:   operator new(unsigned, std::nothrow_t const&)

--20333-- Massif:   operator new[](unsigned, std::nothrow_t const&)

--20333-- Massif:   operator new(unsigned long, std::nothrow_t const&)

--20333-- Massif:   operator new[](unsigned long, std::nothrow_t const&)

--20333-- Massif: ignore-fns:

--20333-- Massif:   <empty>

--20333-- Reading syms from /system/bin/mcfPQ

--20333-- Reading syms from /system/bin/linker64

--20333-- Reading syms from /system/lib64/valgrind/massif-arm64-linux

--20333--    object doesn't have a dynamic symbol table

--20333-- Scheduler: using generic scheduler lock implementation.

CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is a directory--------------------------why it link failed with –pages-as-heap ?  How can I resovle it ?

libc: CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is a directory

libc: Fatal signal 6 (SIGABRT), code -6 in tid 20333 (massif-arm64-li)

libc: Unable to open connection to debuggerd: Connection refused

--20333-- WARNING: unhandled arm64-linux syscall: 240

==20333==    at 0x40D8B80: __dl_syscall (syscall.S:44)

==20333==    by 0x4007397: __dl__ZL24debuggerd_signal_handleriP7siginfoPv (debugger.cpp:294)

==20333==    by 0x38088B8B: ??? (in /system/lib64/valgrind/massif-arm64-linux)

--20333-- You may be able to write your own handler.

--20333-- Read the file README_MISSING_SYSCALL_OR_IOCTL.

--20333-- Nevertheless we consider this a bug.  Please report

--20333-- it at http://valgrind.org/support/bug_reports.html.

libc: failed to resend signal during crash: Function not implemented


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

Philippe Waroquiers
On Mon, 2017-04-17 at 06:36 +0000, Wuweijia wrote:
>  
>
> The output as below:
...
> localhost:/system/bin # LD_PRELOAD=/system/bin/linker64 ./valgrind
> --tool=massif -v  --pages-as-heap=yes  ./mcfPQ
> --gtest_filter=*DISTANCE_001_001*
...

> CANNOT LINK EXECUTABLE "./mcfPQ": can't read file "/system/lib64": Is
> a directory--------------------------why it link failed with –
> pages-as-heap ?  How can I resovle it ?
>
> libc: CANNOT LINK EXECUTABLE "./mcfPQ": can't read file
> "/system/lib64": Is a directory
>
> libc: Fatal signal 6 (SIGABRT), code -6 in tid 20333 (massif-arm64-li)
>
> libc: Unable to open connection to debuggerd: Connection refused
>

--pages-as-heap=yes means massif will do some hacks on the LD_PRELOAD
variable to remove the preloaded valgrind shared object that replaces
malloc/free/...

So a guess is that there is a bad interaction between your LD_PRELOAD
setting to /system/bin/linker64 and the way massif modifies LD_PRELOAD
for --pages-as-heap=yes.

A few questions:
Is this an android platform ?
why do you need to set this variable ?

The best is probably to file a bug report on bugzilla with
the above information
and attach the output of
   valgrind --tool=massif -v -v -v -d -d -d --pages-as-heap=yes --trace-syscalls=yes ....
and
   valgrind --tool=massif -v -v -v -d -d -d --pages-as-heap=no  --trace-syscalls=yes ....


Philippe



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 答复: [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

Philippe Waroquiers
On Tue, 2017-04-18 at 02:33 +0000, Wuweijia wrote:
> Hi Philippe:
>   This is the android project.
>  
>   No matter the LD_PRELOAD , the valgrind always failed. The output is the same.
>  
>   I do not want to set it , I just try it when run the massif failed with --pages-as-heap and no LD_PRELOAD.
>
>   I can not access web address. So can you help me to create a bug report and analyze it .

Looking at the traces you have sent, we see that in the working run,
we have 2 successive open syscalls:
run_with_page_as_heap_no.log:381:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ...
run_with_page_as_heap_no.log:412:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d090(/system/lib64/valgrind/vgpreload_massif-arm64-linux.so), 524288 ) --> [async] ...

the failed run contains:
run_with_page_as_heap_yes.log:2063:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ...
run_with_page_as_heap_yes.log:2139:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0xffeffe908(/system/lib64/), 524288 ) --> [async] ...

Massif uses a hack to remove vgpreload_massif-arm64-linux.so from the LD_PRELOAD, by replacing the
full entry with spaces.
I am guessing that on android, the dynamic linker tries to open such an 'all spaces' entry by appending
it to a system lib path, causing then the open syscall to fail and cause a dynamic linking error.

I have reworked the way vgpreload_massif-arm64-linux.so is removed from LD_PRELOAD,
as part of revision 16306, so that the entry is really removed, rather than replaced
with spaces.

Can you get + compile + test the SVN version ?
(see http://www.valgrind.org/downloads/repository.html
to get the SVN version, README.android indicates how to
build for android)

Thanks

Philippe



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

答复: 答复: [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

Wuweijia
Hi
   I can not access svn address that you show me. Can you show the code you modify, and I merge it .

BR
Owen

-----邮件原件-----
发件人: Philippe Waroquiers [mailto:[hidden email]]
发送时间: 2017年4月20日 4:23
收件人: Wuweijia <[hidden email]>
抄送: [hidden email]; Fanbohao <[hidden email]>
主题: Re: 答复: [Valgrind-users] [Help] I run test application throght the massif with --pages-as-heap, it failed. But I run the same application throught the massif with no --pages-as-heap, it is ok.why?

On Tue, 2017-04-18 at 02:33 +0000, Wuweijia wrote:
> Hi Philippe:
>   This is the android project.
>  
>   No matter the LD_PRELOAD , the valgrind always failed. The output is the same.
>  
>   I do not want to set it , I just try it when run the massif failed with --pages-as-heap and no LD_PRELOAD.
>
>   I can not access web address. So can you help me to create a bug report and analyze it .

Looking at the traces you have sent, we see that in the working run, we have 2 successive open syscalls:
run_with_page_as_heap_no.log:381:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ...
run_with_page_as_heap_no.log:412:SYSCALL[25925,1](56) sys_openat ( 4294967196, 0x494d090(/system/lib64/valgrind/vgpreload_massif-arm64-linux.so), 524288 ) --> [async] ...

the failed run contains:
run_with_page_as_heap_yes.log:2063:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0x494d050(/system/lib64/valgrind/vgpreload_core-arm64-linux.so), 524288 ) --> [async] ...
run_with_page_as_heap_yes.log:2139:SYSCALL[25913,1](56) sys_openat ( 4294967196, 0xffeffe908(/system/lib64/), 524288 ) --> [async] ...

Massif uses a hack to remove vgpreload_massif-arm64-linux.so from the LD_PRELOAD, by replacing the full entry with spaces.
I am guessing that on android, the dynamic linker tries to open such an 'all spaces' entry by appending it to a system lib path, causing then the open syscall to fail and cause a dynamic linking error.

I have reworked the way vgpreload_massif-arm64-linux.so is removed from LD_PRELOAD, as part of revision 16306, so that the entry is really removed, rather than replaced with spaces.

Can you get + compile + test the SVN version ?
(see http://www.valgrind.org/downloads/repository.html
to get the SVN version, README.android indicates how to build for android)

Thanks

Philippe


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Loading...