valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[John R. <jr...@bi...>]

> For a simple example, just compare the results of ``strace date'' and ``valgrind --trace-syscalls=yes date'' on Linux.
>
> E.g., it records syscalls only related to Valgrind, like
> sys_open ( 0x40244a0(/usr/local/lib/valgrind/vgpreload_core-amd64-linux.so)
> sys_open ( 0x40249d8(/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>
> It also has other different operations like memory/signal/file operations, sysctl, etc.
>
> How to tell which are extra ones caused by Valgrind, which are not?

A filename which contains "valgrind/vgpreload_<tool-name>-<arch-name>-<os-name>.so"
gives a hint that syscalls (or calls to wrappers for syscalls)
from such a file should be re-directed to the non-traced versions.
Depending on the details of how the current non-interception operates,
such re-direction could be done when processing pre-loaded libraries,
or might require a dynamic check of the program counter
for every syscall that is simulated.

[Valgrind-users] el capitan support

[fh <f....@gm...>]

Does anyone have an El Capitan os x working Valgrind version?

thanks ^^

email me at f....@gm...

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Yue C. <yc...@gm...>]

For a simple example, just compare the results of ``strace date'' and
``valgrind --trace-syscalls=yes date'' on Linux.

E.g., it records syscalls only related to Valgrind, like
sys_open ( 0x40244a0(/usr/local/lib/valgrind/vgpreload_core-amd64-linux.so)
sys_open (
0x40249d8(/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so)

It also has other different operations like memory/signal/file operations,
sysctl, etc.

How to tell which are extra ones caused by Valgrind, which are not?


On Tue, Sep 8, 2015 at 3:41 AM, Tom Hughes <to...@co...> wrote:

> On 08/09/15 07:43, Yue Chen wrote:
>
> I mean the result from
>>
>> "valgrind --trace-syscalls=yes ./myprogram"   VS   "truss ./myprogram"
>> are different;
>>
>> NOT
>> "truss valgrind --trace-syscalls=yes ./program"  VS  "truss ./program".
>>
>> Can I modify some Valgrind source code to mark the syscalls issued from
>> Valgrind itself?
>>
>
> You're confused. The --trace-syscalls flag only shows system calls issued
> by your program. The only thing that would show those issued by valgrind
> itself is trussing valgrind, ie the first option in your second version.
>
> Many things might be influencing which system calls the C library uses to
> implement a given library call however, and it may be that the environment
> valgrind provides is different in some way that causes the library to make
> a different choice.
>
> I really wouldn't worry too much if you see odd differences here, but if
> you really want us to comment on possible reasons you will likely need to
> provide concrete examples.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] symbol look up error in helgrind

[Tushar N. <nt...@ya...>]

I forgot to add the version of valgrind.  The version is r15654.
The stable release also shows the same issue
Thanks
      From: Tushar Nair <nt...@ya...>
 To: "val...@li..." <val...@li...> 
 Sent: Saturday, September 19, 2015 6:46 PM
 Subject: symbol look up error in helgrind
   
Hello,
When running my program in helgrind it dies after printing the following error on screen
==25217== Warning: client switching stacks?  SP change: 0xffefff318 --> 0x2ec302fc21b27bd
==25217==          to suppress, use: --max-stackframe=210596195555030181 or greater
==25217== 
==25217== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==25217==  Bad permissions for mapped region at address 0x2EC302AC21B4ABF
==25217==    at 0x2EC302AC21B4ABF: ???
==25217== 

Running in gdb the stack trace before the crash is 

(gdb) where
#0  __libc_dl_error_tsd () at dl-tsd.c:51
#1  0x0000003a5220d205 in _dl_signal_error (errcode=0, objname=0x4801338 "/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so", occation=0x3a522189af "symbol lookup error", errstring=0xffeffeee0 "undefined symbol: pthread_mutexattr_gettype") at dl-error.c:79
#2  0x0000003a5220d3d4 in _dl_signal_cerror (errcode=0, objname=0x4801338 "/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so", occation=0x3a522189af "symbol lookup error", errstring=0xffeffeee0 "undefined symbol: pthread_mutexattr_gettype") at dl-error.c:152
#3  0x0000003a52209cf0 in _dl_lookup_symbol_x (undef_name=0x4a0706d "pthread_mutexattr_gettype", undef_map=0x4801370, ref=0xffefff080, symbol_scope=0x48016d0, version=0x0, type_class=1, flags=1, skip_map=0x0) at dl-lookup.c:321
#4  0x0000003a5220cfb5 in _dl_fixup (l=0x0, reloc_offset=<value optimized out>) at dl-runtime.c:108
#5  0x0000003a52212a32 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000004a10731 in _vgw00000ZZ_libpthreadZdsoZd0_pthreadZumutexZuinit (mutex=0x5084ca0, attr=0xffefff1a0) at hg_intercepts.c:771
#7  0x000000000644830f in decaf::internal::util::concurrent::PlatformThread::createMutex (mutex=0x5084b68) at decaf/internal/util/concurrent/unix/PlatformThread.cpp:79
#8  0x0000000006445974 in decaf::internal::util::concurrent::Threading::initialize () at decaf/internal/util/concurrent/Threading.cpp:869
#9  0x00000000063eca2a in decaf::lang::Runtime::initializeRuntime (argc=0, argv=0x0) at decaf/internal/DecafRuntime.cpp:76
#10 0x000000000621ed39 in activemq::library::ActiveMQCPP::initializeLibrary (argc=0, argv=0x4801338) at activemq/library/ActiveMQCPP.cpp:57
#11 0x00000000054b1022 in ktSecFwIni () at ../ktcs/KTSecFWIniFini.cpp:18
#12 0x00000000054bb106 in __do_global_ctors_aux () from /lib64/security/pam_ktcs.so
#13 0x000000000548f433 in _init () from /lib64/security/pam_ktcs.so
#14 0x00000000054881fc in ?? () from /lib64/security/pam_ktcs.so
#15 0x0000003a5220d4ab in call_init (l=0x56cd4a8, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-init.c:70
#16 0x0000003a5220d5b5 in _dl_init (main_map=0x5068ac0, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-init.c:134
#17 0x0000003a52211054 in dl_open_worker (a=<value optimized out>) at dl-open.c:506
#18 0x0000003a5220d136 in _dl_catch_error (objname=0xffefff570, errstring=0xffefff568, mallocedp=0xffefff57f, operate=0x3a52210d80 <dl_open_worker>, args=0xffefff520) at dl-error.c:178
#19 0x0000003a522108bc in _dl_open (file=0x5068a60 "/lib64/security/pam_ktcs.so", mode=-2147483646, caller_dlopen=0x3a57e0480a, nsid=-2, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-open.c:586
#20 0x0000003a52e00f9a in dlopen_doit (a=<value optimized out>) at dlopen.c:67
#21 0x0000003a5220d136 in _dl_catch_error (objname=0x3a530030d0, errstring=0x3a530030d8, mallocedp=0x3a530030c8, operate=0x3a52e00f30 <dlopen_doit>, args=0xffefff740) at dl-error.c:178
#22 0x0000003a52e0150d in _dlerror_run (operate=0x3a52e00f30 <dlopen_doit>, args=0xffefff740) at dlerror.c:164
#23 0x0000003a52e00f11 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88
#24 0x0000003a57e0480a in ?? () from /lib64/libpam.so.0
#25 0x0000003a57e04ffb in ?? () from /lib64/libpam.so.0
#26 0x0000003a57e05338 in ?? () from /lib64/libpam.so.0
#27 0x0000003a57e05a58 in ?? () from /lib64/libpam.so.0
#28 0x0000003a57e07174 in pam_start () from /lib64/libpam.so.0
#29 0x0000000000400e29 in main (argc=1, argv=0xffeffffd8) at ../pam_ktcs_test/CheckUser.cc:59
(gdb) 
The code runs fine in memgrind and outside valgrind.  The stack trace when the program is run without valgrind is
(gdb) where
#0  __pthread_mutex_init (mutex=0x619220, mutexattr=0x7fffffffd150) at pthread_mutex_init.c:42
#1  0x00002aaaabee130f in decaf::internal::util::concurrent::PlatformThread::createMutex (mutex=0x619148) at decaf/internal/util/concurrent/unix/PlatformThread.cpp:79
#2  0x00002aaaabede974 in decaf::internal::util::concurrent::Threading::initialize () at decaf/internal/util/concurrent/Threading.cpp:869
#3  0x00002aaaabe85a2a in decaf::lang::Runtime::initializeRuntime (argc=0, argv=0x0) at decaf/internal/DecafRuntime.cpp:76
#4  0x00002aaaabcb7d39 in activemq::library::ActiveMQCPP::initializeLibrary (argc=6394400, argv=0x7fffffffd150) at activemq/library/ActiveMQCPP.cpp:57
#5  0x00002aaaaaf4a022 in ktSecFwIni () at ../ktcs/KTSecFWIniFini.cpp:18
#6  0x00002aaaaaf54106 in __do_global_ctors_aux () from /lib64/security/pam_ktcs.so
#7  0x00002aaaaaf28433 in _init () from /lib64/security/pam_ktcs.so
#8  0x00002aaaaaf211fc in ?? () from /lib64/security/pam_ktcs.so
#9  0x0000003a5220d4ab in call_init (l=0x2aaaab1664a8, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-init.c:70
#10 0x0000003a5220d5b5 in _dl_init (main_map=0x6038c0, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-init.c:134
#11 0x0000003a52211054 in dl_open_worker (a=<value optimized out>) at dl-open.c:506
#12 0x0000003a5220d136 in _dl_catch_error (objname=0x7fffffffd520, errstring=0x7fffffffd518, mallocedp=0x7fffffffd52f, operate=0x3a52210d80 <dl_open_worker>, args=0x7fffffffd4d0) at dl-error.c:178
#13 0x0000003a522108bc in _dl_open (file=0x603890 "/lib64/security/pam_ktcs.so", mode=-2147483646, caller_dlopen=0x3a57e0480a, nsid=-2, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-open.c:586
#14 0x0000003a52e00f9a in dlopen_doit (a=<value optimized out>) at dlopen.c:67
#15 0x0000003a5220d136 in _dl_catch_error (objname=0x3a530030d0, errstring=0x3a530030d8, mallocedp=0x3a530030c8, operate=0x3a52e00f30 <dlopen_doit>, args=0x7fffffffd6f0) at dl-error.c:178
#16 0x0000003a52e0150d in _dlerror_run (operate=0x3a52e00f30 <dlopen_doit>, args=0x7fffffffd6f0) at dlerror.c:164
#17 0x0000003a52e00f11 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88
#18 0x0000003a57e0480a in ?? () from /lib64/libpam.so.0
#19 0x0000003a57e04ffb in ?? () from /lib64/libpam.so.0
#20 0x0000003a57e05338 in ?? () from /lib64/libpam.so.0
#21 0x0000003a57e05a58 in ?? () from /lib64/libpam.so.0
#22 0x0000003a57e07174 in pam_start () from /lib64/libpam.so.0
#23 0x0000000000400e29 in main (argc=1, argv=0x7fffffffdf88) at ../pam_ktcs_test/CheckUser.cc:59
(gdb) 
The function in question is shown below
  61 ////////////////////////////////////////////////////////////////////////////////
  62 void PlatformThread::createMutex(decaf_mutex_t* mutex) {
  63 
  64     pthread_mutexattr_t attr;
  65 
  66     if(pthread_mutexattr_init(&attr) != 0 ) {
  67         throw RuntimeException(
  68             __FILE__, __LINE__, "Failed to create OS Mutex attribute object." );
  69     }
  70 
  71     if(pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK) != 0 ) {
  72         pthread_mutexattr_destroy(&attr);
  73         throw RuntimeException(
  74             __FILE__, __LINE__, "Failed to set mutex type in OS Mutex attribute object." );
  75     }
  76 
  77     *mutex = new pthread_mutex_t;
  78 
  79     if( pthread_mutex_init(*mutex, &attr) != 0 ) {
  80         pthread_mutexattr_destroy(&attr);
  81         delete *mutex;
  82         *mutex = 0;
  83         throw RuntimeException(
  84             __FILE__, __LINE__, "Failed to create OS Mutex object." );
  85     }
  86 
  87     pthread_mutexattr_destroy(&attr);
  88 }
  89 
  90 ////////////////////////////////////////////////////////////////////////////////
There are other pthread_XXX functions before the call in question and they have no issues.  Only pthread_mutex_init seems to have a problem.  The problem is repeatable.  Any explanation on what is going and how to address it is very much appreciated.  I'm willing to try any experimental code to get more information or try a fix
Thank you


  

[Valgrind-users] symbol look up error in helgrind

[Tushar N. <nt...@ya...>]

Hello,
When running my program in helgrind it dies after printing the following error on screen
==25217== Warning: client switching stacks?  SP change: 0xffefff318 --> 0x2ec302fc21b27bd
==25217==          to suppress, use: --max-stackframe=210596195555030181 or greater
==25217== 
==25217== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==25217==  Bad permissions for mapped region at address 0x2EC302AC21B4ABF
==25217==    at 0x2EC302AC21B4ABF: ???
==25217== 

Running in gdb the stack trace before the crash is 

(gdb) where
#0  __libc_dl_error_tsd () at dl-tsd.c:51
#1  0x0000003a5220d205 in _dl_signal_error (errcode=0, objname=0x4801338 "/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so", occation=0x3a522189af "symbol lookup error", errstring=0xffeffeee0 "undefined symbol: pthread_mutexattr_gettype") at dl-error.c:79
#2  0x0000003a5220d3d4 in _dl_signal_cerror (errcode=0, objname=0x4801338 "/usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so", occation=0x3a522189af "symbol lookup error", errstring=0xffeffeee0 "undefined symbol: pthread_mutexattr_gettype") at dl-error.c:152
#3  0x0000003a52209cf0 in _dl_lookup_symbol_x (undef_name=0x4a0706d "pthread_mutexattr_gettype", undef_map=0x4801370, ref=0xffefff080, symbol_scope=0x48016d0, version=0x0, type_class=1, flags=1, skip_map=0x0) at dl-lookup.c:321
#4  0x0000003a5220cfb5 in _dl_fixup (l=0x0, reloc_offset=<value optimized out>) at dl-runtime.c:108
#5  0x0000003a52212a32 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#6  0x0000000004a10731 in _vgw00000ZZ_libpthreadZdsoZd0_pthreadZumutexZuinit (mutex=0x5084ca0, attr=0xffefff1a0) at hg_intercepts.c:771
#7  0x000000000644830f in decaf::internal::util::concurrent::PlatformThread::createMutex (mutex=0x5084b68) at decaf/internal/util/concurrent/unix/PlatformThread.cpp:79
#8  0x0000000006445974 in decaf::internal::util::concurrent::Threading::initialize () at decaf/internal/util/concurrent/Threading.cpp:869
#9  0x00000000063eca2a in decaf::lang::Runtime::initializeRuntime (argc=0, argv=0x0) at decaf/internal/DecafRuntime.cpp:76
#10 0x000000000621ed39 in activemq::library::ActiveMQCPP::initializeLibrary (argc=0, argv=0x4801338) at activemq/library/ActiveMQCPP.cpp:57
#11 0x00000000054b1022 in ktSecFwIni () at ../ktcs/KTSecFWIniFini.cpp:18
#12 0x00000000054bb106 in __do_global_ctors_aux () from /lib64/security/pam_ktcs.so
#13 0x000000000548f433 in _init () from /lib64/security/pam_ktcs.so
#14 0x00000000054881fc in ?? () from /lib64/security/pam_ktcs.so
#15 0x0000003a5220d4ab in call_init (l=0x56cd4a8, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-init.c:70
#16 0x0000003a5220d5b5 in _dl_init (main_map=0x5068ac0, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-init.c:134
#17 0x0000003a52211054 in dl_open_worker (a=<value optimized out>) at dl-open.c:506
#18 0x0000003a5220d136 in _dl_catch_error (objname=0xffefff570, errstring=0xffefff568, mallocedp=0xffefff57f, operate=0x3a52210d80 <dl_open_worker>, args=0xffefff520) at dl-error.c:178
#19 0x0000003a522108bc in _dl_open (file=0x5068a60 "/lib64/security/pam_ktcs.so", mode=-2147483646, caller_dlopen=0x3a57e0480a, nsid=-2, argc=1, argv=0xffeffffd8, env=0xffeffffe8) at dl-open.c:586
#20 0x0000003a52e00f9a in dlopen_doit (a=<value optimized out>) at dlopen.c:67
#21 0x0000003a5220d136 in _dl_catch_error (objname=0x3a530030d0, errstring=0x3a530030d8, mallocedp=0x3a530030c8, operate=0x3a52e00f30 <dlopen_doit>, args=0xffefff740) at dl-error.c:178
#22 0x0000003a52e0150d in _dlerror_run (operate=0x3a52e00f30 <dlopen_doit>, args=0xffefff740) at dlerror.c:164
#23 0x0000003a52e00f11 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88
#24 0x0000003a57e0480a in ?? () from /lib64/libpam.so.0
#25 0x0000003a57e04ffb in ?? () from /lib64/libpam.so.0
#26 0x0000003a57e05338 in ?? () from /lib64/libpam.so.0
#27 0x0000003a57e05a58 in ?? () from /lib64/libpam.so.0
#28 0x0000003a57e07174 in pam_start () from /lib64/libpam.so.0
#29 0x0000000000400e29 in main (argc=1, argv=0xffeffffd8) at ../pam_ktcs_test/CheckUser.cc:59
(gdb) 
The code runs fine in memgrind and outside valgrind.  The stack trace when the program is run without valgrind is
(gdb) where
#0  __pthread_mutex_init (mutex=0x619220, mutexattr=0x7fffffffd150) at pthread_mutex_init.c:42
#1  0x00002aaaabee130f in decaf::internal::util::concurrent::PlatformThread::createMutex (mutex=0x619148) at decaf/internal/util/concurrent/unix/PlatformThread.cpp:79
#2  0x00002aaaabede974 in decaf::internal::util::concurrent::Threading::initialize () at decaf/internal/util/concurrent/Threading.cpp:869
#3  0x00002aaaabe85a2a in decaf::lang::Runtime::initializeRuntime (argc=0, argv=0x0) at decaf/internal/DecafRuntime.cpp:76
#4  0x00002aaaabcb7d39 in activemq::library::ActiveMQCPP::initializeLibrary (argc=6394400, argv=0x7fffffffd150) at activemq/library/ActiveMQCPP.cpp:57
#5  0x00002aaaaaf4a022 in ktSecFwIni () at ../ktcs/KTSecFWIniFini.cpp:18
#6  0x00002aaaaaf54106 in __do_global_ctors_aux () from /lib64/security/pam_ktcs.so
#7  0x00002aaaaaf28433 in _init () from /lib64/security/pam_ktcs.so
#8  0x00002aaaaaf211fc in ?? () from /lib64/security/pam_ktcs.so
#9  0x0000003a5220d4ab in call_init (l=0x2aaaab1664a8, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-init.c:70
#10 0x0000003a5220d5b5 in _dl_init (main_map=0x6038c0, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-init.c:134
#11 0x0000003a52211054 in dl_open_worker (a=<value optimized out>) at dl-open.c:506
#12 0x0000003a5220d136 in _dl_catch_error (objname=0x7fffffffd520, errstring=0x7fffffffd518, mallocedp=0x7fffffffd52f, operate=0x3a52210d80 <dl_open_worker>, args=0x7fffffffd4d0) at dl-error.c:178
#13 0x0000003a522108bc in _dl_open (file=0x603890 "/lib64/security/pam_ktcs.so", mode=-2147483646, caller_dlopen=0x3a57e0480a, nsid=-2, argc=1, argv=0x7fffffffdf88, env=0x7fffffffdf98) at dl-open.c:586
#14 0x0000003a52e00f9a in dlopen_doit (a=<value optimized out>) at dlopen.c:67
#15 0x0000003a5220d136 in _dl_catch_error (objname=0x3a530030d0, errstring=0x3a530030d8, mallocedp=0x3a530030c8, operate=0x3a52e00f30 <dlopen_doit>, args=0x7fffffffd6f0) at dl-error.c:178
#16 0x0000003a52e0150d in _dlerror_run (operate=0x3a52e00f30 <dlopen_doit>, args=0x7fffffffd6f0) at dlerror.c:164
#17 0x0000003a52e00f11 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88
#18 0x0000003a57e0480a in ?? () from /lib64/libpam.so.0
#19 0x0000003a57e04ffb in ?? () from /lib64/libpam.so.0
#20 0x0000003a57e05338 in ?? () from /lib64/libpam.so.0
#21 0x0000003a57e05a58 in ?? () from /lib64/libpam.so.0
#22 0x0000003a57e07174 in pam_start () from /lib64/libpam.so.0
#23 0x0000000000400e29 in main (argc=1, argv=0x7fffffffdf88) at ../pam_ktcs_test/CheckUser.cc:59
(gdb) 
The function in question is shown below
  61 ////////////////////////////////////////////////////////////////////////////////
  62 void PlatformThread::createMutex(decaf_mutex_t* mutex) {
  63 
  64     pthread_mutexattr_t attr;
  65 
  66     if(pthread_mutexattr_init(&attr) != 0 ) {
  67         throw RuntimeException(
  68             __FILE__, __LINE__, "Failed to create OS Mutex attribute object." );
  69     }
  70 
  71     if(pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK) != 0 ) {
  72         pthread_mutexattr_destroy(&attr);
  73         throw RuntimeException(
  74             __FILE__, __LINE__, "Failed to set mutex type in OS Mutex attribute object." );
  75     }
  76 
  77     *mutex = new pthread_mutex_t;
  78 
  79     if( pthread_mutex_init(*mutex, &attr) != 0 ) {
  80         pthread_mutexattr_destroy(&attr);
  81         delete *mutex;
  82         *mutex = 0;
  83         throw RuntimeException(
  84             __FILE__, __LINE__, "Failed to create OS Mutex object." );
  85     }
  86 
  87     pthread_mutexattr_destroy(&attr);
  88 }
  89 
  90 ////////////////////////////////////////////////////////////////////////////////
There are other pthread_XXX functions before the call in question and they have no issues.  Only pthread_mutex_init seems to have a problem.  The problem is repeatable.  Any explanation on what is going and how to address it is very much appreciated.  I'm willing to try any experimental code to get more information or try a fix
Thank you

Re: [Valgrind-users] The stack traces given by Memcheck on ARM are missing information

[John O'S. <joh...@cl...>]

I think I have found the issue, the libraries in /usr/lib/valgrind were 
being stripped as part of the rootfs build, excluding these from 
stripping now gives me

  valgrind --leak-check=full  --track-origins=yes --num-callers=4 /work/test
==1240== Memcheck, a memory error detector
==1240== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==1240== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==1240== Command: /work/test
==1240==
==1240== Invalid write of size 4
==1240==    at 0x8680: f (test.c:6)
==1240==    by 0x869B: main (test.c:13)
==1240==  Address 0x49b5050 is 0 bytes after a block of size 40 alloc'd
==1240==    at 0x4837774: malloc (vg_replace_malloc.c:270)
==1240==    by 0x866B: f (test.c:5)
==1240==    by 0x869B: main (test.c:13)
==1240==
==1240==
==1240== HEAP SUMMARY:
==1240==     in use at exit: 40 bytes in 1 blocks
==1240==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==1240==
==1240== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==1240==    at 0x4837774: malloc (vg_replace_malloc.c:270)
==1240==    by 0x866B: f (test.c:5)
==1240==    by 0x869B: main (test.c:13)
==1240==
==1240== LEAK SUMMARY:
==1240==    definitely lost: 40 bytes in 1 blocks
==1240==    indirectly lost: 0 bytes in 0 blocks

On 17/09/15 09:46, John O'Sullivan wrote:
> valgrind --leak-check=full  --track-origins=yes --num-callers=4 /work/test

[Valgrind-users] The stack traces given by Memcheck on ARM are missing information

[John O'S. <joh...@cl...>]

Hi,
I have recently managed to get Valgrind running on an ARM  Zynq Cortex 
A9 based embedded system. I have a simple test program as shown, the  
output is shown below,
Does anyone know why this in the case of the output for the memory leak 
there is not a full stack trace.
at 0x4837774: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
I use gdbserver and eclipse based gdb debugging on this system and have 
no difficulty getting full stack traces so I would like to understand if 
it is possible to locate actual source of memory leaks.
I have read the advice given at
http://valgrind.org/docs/manual/faq.html#faq.unhelpful

---------------------------------------------------------------
compiled with the following cflags

-funwind-tables -mapcs-frame -fno-omit-frame-pointer -fno-stack-check -O0


#include <stdlib.h>

void f()
{
   int * x = malloc(10 * sizeof(int));
   x[10] = 0;        // problem 1: heap block overrun
}              // problem 2: memory leak -- x not freed



int main(void)
  {
     f();
     return 0;
  }


valgrind --leak-check=full  --track-origins=yes --num-callers=4 /work/test

==10738== Memcheck, a memory error detector
==10738== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==10738== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==10738== Command: /work/test
==10738==
==10738== Invalid write of size 4
==10738==    at 0x8680: f (test.c:6)
==10738==    by 0x869B: main (test.c:13)
==10738==  Address 0x49b5050 is 0 bytes after a block of size 40 alloc'd
==10738==    at 0x4837774: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==10738==
==10738==
==10738== HEAP SUMMARY:
==10738==     in use at exit: 40 bytes in 1 blocks
==10738==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==10738==
==10738== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==10738==    at 0x4837774: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==10738==
==10738== LEAK SUMMARY:
==10738==    definitely lost: 40 bytes in 1 blocks
==10738==    indirectly lost: 0 bytes in 0 blocks
==10738==      possibly lost: 0 bytes in 0 blocks
==10738==    still reachable: 0 bytes in 0 blocks
==10738==         suppressed: 0 bytes in 0 blocks
==10738==
==10738== For counts of detected and suppressed errors, rerun with: -v
==10738== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 6)


Regards
John

[Valgrind-users] Mapping from instrumented instruction address to real instruction address in ``--tool=lackey --trace-mem=yes''

[Yue C. <yc...@gm...>]

Hi all,

When doing memory tracing using tool lackey (--tool=lackey
--trace-mem=yes), the instruction addresses recorded seem different from
the original program's. (e.g., ``I  04002166,2'')

Is there any way that I can translate this address to the original one, or
how can I know the instruction content (e.g., movq $1, %rax) from this
recorded address?

Best,

[Valgrind-users] Adding rounding mode support to Valgrind

[Deene D. <Dee...@ma...>]

Hi all,

Just curious if there has been any recent news on getting rounding mode support in Valgrind?
Specifically, I would like to be able to run CGAL on Valgrind.

Bug 136779 - Adding rounding mode support to Valgrind,  includes some patches but the comments died off in 2013.
e.g.  Thomas Rast 2013-05-17 14:50:34 UTC

I'm willing to try any patches if there is a chance they will allow me to not have to rebuild CGAL and disable rounding mode testing.

Thanks
Deene

Re: [Valgrind-users] Working directory

[Mark C. <ma...@ne...>]

Valgrind Users,

Many thanks to Philippe and John for helping me out with this. As
rightly pointed out, valgrind shouldn't and doesn't alter the working
directory so it was, indeed, something else preventing access to the
data files. By using valgrind + vgdb I stepped through the code and
found that the config file wasn't being opened because the code uses the
process name to determine what 'conf' file to open. Clearly, under
valgrind (default) the process name is not the program name and is in
fact memcheck-x86-li.

Having sorted the above issue valgrind successfully determined where the
heap corruption was occurring - a silly coding error in the test harness.

Regards,

Mark
****
Triathlete, climber, and mediocre pianist
 - aspiring to be just a little bit better than last year
---
Co-founder of Woodland Friends: www.woodlandfriends.co.uk
 - replanting native British woodland for the benefit of communities and
wildlife


On 10/09/15 21:36, Philippe Waroquiers wrote:
> On Thu, 2015-09-10 at 09:40 +0100, Mark Chimley wrote:
>> Folks,
>>
>> This is hopefully a question with an easy answer. I've got a program
>> which seems to cause heap corruption so I thought valgrind would be able
>> to tell me where this occurs. The trouble is the program uses data files
>> from the running directory for configuration purposes and running the
>> program under valgrind seems to prevent it finding these data files. I
>> therefore cannot reproduce the conditions which cause the problem.
>>
>> I've looked in the manual, help and FAQs for how to set the working
>> directory but I cannot find anything related to this. I feel I must be
>> missing something quite obvious as this would appear to be quite a
>> fundamental issue.
>>
> For sure, if valgrind would fiddle with the working directory,
> then a lot of things would not work properly.
> As an example, doing
>    valgrind pwd
> properly shows the current working directory where you launch valgrind.
> 
> So, something else must happen.
> 
> What you could do is to run your application with
>    valgrind --trace-syscalls=yes ....
> and see e.g. which open syscall is unexpectedly failing.
> 
> Alternatively, start your application with valgrind+vgdb,
> and put breakpoints at the relevant places to see why the
> required files are not being opened.
> (see
> http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
> for more info about debugging your application running under valgrind).
> 
> 
> Philippe
> 
> 
> 
> 

Re: [Valgrind-users] Working directory

[Philippe W. <phi...@sk...>]

On Thu, 2015-09-10 at 09:40 +0100, Mark Chimley wrote:
> Folks,
> 
> This is hopefully a question with an easy answer. I've got a program
> which seems to cause heap corruption so I thought valgrind would be able
> to tell me where this occurs. The trouble is the program uses data files
> from the running directory for configuration purposes and running the
> program under valgrind seems to prevent it finding these data files. I
> therefore cannot reproduce the conditions which cause the problem.
> 
> I've looked in the manual, help and FAQs for how to set the working
> directory but I cannot find anything related to this. I feel I must be
> missing something quite obvious as this would appear to be quite a
> fundamental issue.
> 
For sure, if valgrind would fiddle with the working directory,
then a lot of things would not work properly.
As an example, doing
   valgrind pwd
properly shows the current working directory where you launch valgrind.

So, something else must happen.

What you could do is to run your application with
   valgrind --trace-syscalls=yes ....
and see e.g. which open syscall is unexpectedly failing.

Alternatively, start your application with valgrind+vgdb,
and put breakpoints at the relevant places to see why the
required files are not being opened.
(see
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
for more info about debugging your application running under valgrind).


Philippe

Re: [Valgrind-users] Working directory

[Dallman, J. <joh...@si...>]

> I've got a program which seems to cause heap corruption so I thought valgrind would be
> able to tell me where this occurs. The trouble is the program uses data files from the
> running directory for configuration purposes and running the program under valgrind
> seems to prevent it finding these data files. I therefore cannot reproduce the
> conditions which cause the problem.

How are you launching your program? The way I do it is to set up a working directory with
the files I need in it, and run the program without Valgrind to verify that it's all set up.

For example, I have kid.out as the executable. with lipsini.lsp as its startup commands.

        ls shows me:
        kid.out lispini.lsp
        kid.out runs it.

Then I just run

        /usr/local/bin/valgrind kid.out

and that runs kid.out under Valgrind with the directory I was in as the current directory.

--
John Dallman


-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

[Valgrind-users] Working directory

[Mark C. <ma...@ne...>]

Folks,

This is hopefully a question with an easy answer. I've got a program
which seems to cause heap corruption so I thought valgrind would be able
to tell me where this occurs. The trouble is the program uses data files
from the running directory for configuration purposes and running the
program under valgrind seems to prevent it finding these data files. I
therefore cannot reproduce the conditions which cause the problem.

I've looked in the manual, help and FAQs for how to set the working
directory but I cannot find anything related to this. I feel I must be
missing something quite obvious as this would appear to be quite a
fundamental issue.

-- 
Mark
****
Triathlete, climber, and mediocre pianist
 - aspiring to be just a little bit better than last year
---
Co-founder of Woodland Friends: www.woodlandfriends.co.uk
 - replanting native British woodland for the benefit of communities and
wildlife

[Valgrind-users] Enable Helgrind on User Level Threading System

[Gu R. <ru...@gm...>]

Dear Valgrind Developers:
My name is Rui Gu, a student from Columbia University. Thanks for building and maintaining such great tool!
Right now, we’re trying to enable Helgrind on UserModeLinux(UML).
We’ve encountered a problem and want to get a clue about the best way of solving it.
Let me put our basic understanding of Valgrind and the problems we encountered here.

Helgrind:
For a thread that is created by pthread_create(). Valgrind first intercept pthread_create() in hg_intercept.c for some threading info registration. Then, coregrind will intercept clone() in syswrap-x86-linux.c to monitor and control the thread creation and execution. Valgrind also supports some self-implemented synchronization primitives by using ANNOTATION.

Question:
In short, we want to ask what’s the most legitimate way of supporting user level thread scheduling system?

The detailed question goes from here:
The problem is that UML will have its own user level threading systems. They use kernel_thread() to create threads and scheduling them on the user level.
The code is like this.
int kernel_thread(int (*fn)(void* ), void * arg, unsigned long flags)
{
     int pid;

     current->thread.request.u.thread.proc = fn;
     current->thread.request.u.thread.arg = arg;
     pid = do_fork(CLONE_VM | CLONE_UNTRACED | flags, 0,
               &current->thread.regs, 0, NULL, NULL);
     return pid;
 }

So, our guess is, in order to let Valgrind detect, monitor and control these threads. We need to first intercept kernel_thread() in hg_intercept.c and then intercept do_fork() in coregrind. Instead of letting coregrind calls clone internally, we’ll have to let Valgrind call do_fork() of UML. 

The problem is right now, it’s kind of hard and strange to let coregrind to call a function within UML. Because coregrind is not supposed to see any guest program APIs and thus there isn’t any related API of doing it. So we’re wondering r we doing it in the right way?

Thanks in advance for your kind support.

Rui

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Tom H. <to...@co...>]

On 08/09/15 07:43, Yue Chen wrote:

> I mean the result from
>
> "valgrind --trace-syscalls=yes ./myprogram"   VS   "truss ./myprogram"
> are different;
>
> NOT
> "truss valgrind --trace-syscalls=yes ./program"  VS  "truss ./program".
>
> Can I modify some Valgrind source code to mark the syscalls issued from
> Valgrind itself?

You're confused. The --trace-syscalls flag only shows system calls 
issued by your program. The only thing that would show those issued by 
valgrind itself is trussing valgrind, ie the first option in your second 
version.

Many things might be influencing which system calls the C library uses 
to implement a given library call however, and it may be that the 
environment valgrind provides is different in some way that causes the 
library to make a different choice.

I really wouldn't worry too much if you see odd differences here, but if 
you really want us to comment on possible reasons you will likely need 
to provide concrete examples.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Yue C. <yc...@gm...>]

I mean the result from

"valgrind --trace-syscalls=yes ./myprogram"   VS   "truss ./myprogram"
are different;

NOT
"truss valgrind --trace-syscalls=yes ./program"  VS  "truss ./program".

Can I modify some Valgrind source code to mark the syscalls issued from
Valgrind itself?



On Tue, Sep 8, 2015 at 2:30 AM, Ivo Raisr <ivo...@gm...> wrote:

>
>
> 2015-09-08 8:10 GMT+02:00 Yue Chen <yc...@gm...>:
>
>> Any approach that can distinguish which syscalls are from the
>> application, and which syscalls are from Valgrind itself?
>>
>
> Based solely on 'truss' output, no.
> I.
>

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Yue C. <yc...@gm...>]

Any approach that can distinguish which syscalls are from the application,
and which syscalls are from Valgrind itself?

On Tue, Sep 8, 2015 at 2:04 AM, Ivo Raisr <ivo...@gm...> wrote:

>
>
> 2015-09-08 1:35 GMT+02:00 Yue Chen <yc...@gm...>:
>
>> I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found
>> that that the results of ``truss'' and ``valgrind --trace-syscalls=yes''
>> are a little different. For example, the result of Valgrind has extra
>> syscalls like sys_sysctl, sys_fstatfs6 and [async].
>> Is it because Valgrind result contains the syscalls issued from the
>> instrumentation code, or something else?
>> Thanks.
>>
>
> Think of Valgrind as a virtual machine.
> Truss observes behaviour of the host (Valgrind itself) while
> --trace-syscalls traces behavior of the guest (your application).
> Valgrind syscall machinery intercepts all syscalls from the application
> and in general they are not mapped 1:1 to native ones.
> Some of these might be changed or intercepted completely.
> Valgrind will also issue syscalls on its own.
> I.
>

Re: [Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Ivo R. <ivo...@gm...>]

2015-09-08 1:35 GMT+02:00 Yue Chen <yc...@gm...>:

> I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found
> that that the results of ``truss'' and ``valgrind --trace-syscalls=yes''
> are a little different. For example, the result of Valgrind has extra
> syscalls like sys_sysctl, sys_fstatfs6 and [async].
> Is it because Valgrind result contains the syscalls issued from the
> instrumentation code, or something else?
> Thanks.
>

Think of Valgrind as a virtual machine.
Truss observes behaviour of the host (Valgrind itself) while
--trace-syscalls traces behavior of the guest (your application).
Valgrind syscall machinery intercepts all syscalls from the application and
in general they are not mapped 1:1 to native ones.
Some of these might be changed or intercepted completely.
Valgrind will also issue syscalls on its own.
I.

[Valgrind-users] Difference between "truss" and "valgrind --trace-syscalls=yes" on FreeBSD

[Yue C. <yc...@gm...>]

Hi,

I tried to use Valgrind syscall tracing utility on FreeBSD 10.1. I found
that that the results of ``truss'' and ``valgrind --trace-syscalls=yes''
are a little different. For example, the result of Valgrind has extra
syscalls like sys_sysctl, sys_fstatfs6 and [async].
Is it because Valgrind result contains the syscalls issued from the
instrumentation code, or something else?
Thanks.

Best,
Yue

Re: [Valgrind-users] Counting instructions for specific part of my code using Callgrind

[Josef W. <Jos...@gm...>]

Am 31.08.2015 um 17:10 schrieb Florian Krohm:
> On 28.08.2015 09:03, Josef Weidendorfer wrote:
> 
>> This suggests we should document the difference between
>> START/STOP_INSTRUMENTAITON
>> and TOGGLE_COLLECT better. 
> 
> Hmm, yes :) Any chance you can write something up in time for 3.11 ?

This is about Section 6.2.2 "Limiting the range of collected events"
in the Callgrind part of Valgrind's manual.

I just rephrased this section. Can you check if this is clearer now?

It should also make clear why switching instrumentation mode often can
get very slow.

>> With macros in C, the compiler can reorder stuff, so you may end up with
>> something like
>
> Huh? CALLGRIND_START_INSTRUMENTATION expands into a statement sequence
> that includes
>    __asm__ volatile("whatever" ::: "memory");

Oops, I stay corrected.

Josef

Re: [Valgrind-users] Counting instructions for specific part of my code using Callgrind

[Florian K. <fl...@ei...>]

On 28.08.2015 09:03, Josef Weidendorfer wrote:

> This suggests we should document the difference between
> START/STOP_INSTRUMENTAITON
> and TOGGLE_COLLECT better. 

Hmm, yes :) Any chance you can write something up in time for 3.11 ?

> 
>>      for (int i = 1; i <= 1000; ++i) {
>>        CALLGRIND_START_INSTRUMENTATION;
>>        n += i;
>>        CALLGRIND_STOP_INSTRUMENTATION;
>>      }
> 
> With macros in C, the compiler can reorder stuff, so you may end up with
> something like
> 
>>      for (int i = 1; i <= 1000; ++i) {
>>        n += i;
>>        CALLGRIND_START_INSTRUMENTATION;
>>        CALLGRIND_STOP_INSTRUMENTATION;
>>      }
> 

Huh? CALLGRIND_START_INSTRUMENTATION expands into a statement sequence
that includes
   __asm__ volatile("whatever" ::: "memory");

and GCC docs say:
<quote>
 If your assembler instructions access memory in an unpredictable
fashion, add 'memory' to the list of clobbered registers.
</quote>

Wouldn't that prevent the CALLGRIND_START_INSTRUMENTATION from being
moved around? Reason being that the memory clobber might change the
value of "i" in a way not visible to the compiler?

   Florian

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[John O'S. <joh...@cl...>]

Hi Florian,

Thanks for your input, Yes that patch helps, I have moved past the 
previous assert and can now at least run valgrind to the point where I hit:

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      memcpy
valgrind:  in an object with soname matching:   ld-linux.so.3
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux.so.3
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

I am using buildroot as my build system so I will look at my 
configuration to see what options I have for this issue.

On 29/08/15 15:44, Florian Krohm wrote:
> if (filename || (dev != 0 && ino != 0))

Re: [Valgrind-users] Jump to invalid address

[John R. <jr...@bi...>]

> (x86, gcc, valgrind v3.10.0)

Thank you for stating that information about the environment!
[Sometimes the output from "gcc --version" and "/lib*/libc.so.N"
also matters, but not in this case.]

> ==20897== Jump to the invalid address stated on the next line
> ==20897==    at 0x810CFFFF: ???
> ==20897==  Address 0x810cffff is not stack'd, malloc'd or (recently) free'd

In general, run with --vgdb-error=0 which enables simultaneous gdb and memcheck.
(Hint: after the initial attach, then gdb is waiting for commands and "continue".)
Then you can plant gdb breakpoints and watch as execution proceeds,
in order to bound and narrow the scope of the problem.

Add a subroutine which turns on the hardware feature which records successful
branches ("branch trace buffer").  This requires a trek through documentation
about the specific CPU and the Linux 'perf' subsystem.

Re: [Valgrind-users] Mac OS X 10.9.4 + Android ndk r6 + Valgrind 3.10.1

[John R. <jr...@bi...>]

> Mac OS X 10.9.4 + Android ndk r6 (on a Snapdragon 800) + Valgrind 3.10.

Thank you for reporting those version identifiers!

>
> When I try to ./configure, I get: checking for the kernel version... unsupported (13.3.0) configure: error: Valgrind works on kernels 2.4, 2.6

./configure is a shell script, so run it as:
	sh -x ./configure
to get a trace of the commands that are being executed.
Inspecting the trace might give a clue about what is happening.

Is "13.3.0" related to any version string in the ndk or the Snapdragon itself?
(Check the Settings for the hardware device.)

Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:

[Florian K. <fl...@ei...>]

It used to be that we considered a segment to be a file segment when
/proc/self/maps showed a file name. Then came https://bugs.kde.org/124528
where somebody reported that his maps file had entries with dev and
inode but no file name. Revision 5818 was checked in to fix that. The
new logic now is that a segment is a file segment if dev and inode are
both != 0.
Presence of a file name does not matter. That fixed the problem but
not completely. See https://bugs.kde.org/124528#c11 where the person
reported lines like these:
38000000-38121000 r-xp 00000000 00:00 8503636
/tmp/valgrind/lib/valgrind/x86-linux/memcheck

which is like the stuff you're seeing. Note: dev == 0 and inode != 0 here.
Perhaps we need to change the logic like so:

Index: coregrind/m_aspacemgr/aspacemgr-linux.c
===================================================================
--- coregrind/m_aspacemgr/aspacemgr-linux.c	(revision 15595)
+++ coregrind/m_aspacemgr/aspacemgr-linux.c	(working copy)
@@ -1510,12 +1510,11 @@
    seg.hasX   = toBool(prot & VKI_PROT_EXEC);
    seg.hasT   = False;

-   /* Don't use the presence of a filename to decide if a segment in
-      the initial /proc/self/maps to decide if the segment is an AnonV
-      or FileV segment as some systems don't report the filename. Use
-      the device and inode numbers instead. Fixes bug #124528. */
+   /* A segment in the initial /proc/self/maps is considered a FileV
+      segment if either it has a file name associated with it or both its
+      device and inode numbers are != 0. See bug #124528. */
    seg.kind = SkAnonV;
-   if (dev != 0 && ino != 0)
+   if (filename || (dev != 0 && ino != 0))
       seg.kind = SkFileV;

 #  if defined(VGO_darwin)


Could you try and see whether that helps?

   Florian



On 28.08.2015 16:06, John OSullivan wrote:
> Hi,
> 
> I have a problem running valgrind on my embedded system, you can see the
> detail below but essentially the problem is that Valgrind fails with:
> FATAL: aspacem assertion failed
> 
> The problem is caused by valgrind detecting a inode number of zero for libc
> b6dae000-b6eea000 r-xp 00000000 00:00 8937       /lib/libc-2.13.so
>                                 ^^^^^
>                                  dev & ino are always zero
> 
> My system boots from nand and copies the file system to ram, so the file
> system runs from ram, as far as I can determine when running from ram the
> device and inode number are going to always be zero.
> I tried a similar exercise with the Raspberry PI, if the PIs file system
> reside in Ram (Volatile) then the device and inodes will always be zero, if
> I put the PIs file system on the SD Card (non volatile) then I get non-zero
> device and inodes for the relevant sections.
> 
> My question is how am I going to use valgrind on a ram based file system
> when device numbers are going to be zero for libc, is there a configuration
> or setting that I am missing.
> 
> Regards
> John O'Sullivan
> 
> 
> 
> device - If the region was mapped from a file, this is the major and minor
> device number (in hex) where the file lives.
> inode - If the region was mapped from a file, this is the file number
> 
> 
> -----Original Message-----
> From: John OSullivan [mailto:joh...@cl...] 
> Sent: 15 April 2015 15:31
> To: js...@ac...; 'Florian Krohm'; val...@li...
> Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
> 
> Hi Guys,
> Thanks for the feedback, I will investigate further regarding the file
> system, the system is built using Buildroot, so I will poke around there too
> see if I can get to the bottom of it.
> 
> Regards
> 
> 
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: 15 April 2015 15:13
> To: Florian Krohm; John OSullivan; val...@li...
> Subject: Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
> 
> On 15/04/15 16:03, Florian Krohm wrote:
> 
>> This isn't sane, because for an ANON segment we should have d=0 and
>> i=0 and o=0.
>> Clearly, this is not an ANON segment but a file segment.
>>
>> I suggest to change the condition on line 3248 in aspacemgr-linux.c 
>> (refering to 3.10.1 sources) to if (1) and rerun. That way we can see 
>> the contents of /proc/self/maps and can deduce why d == 0  (it should 
>> be != 0).
> 
> Ah, good point.
> 
> So, d is the device number, right?  If that's so, then the problem is likely
> because memcheck-arm-linux is on some unusual, hacky, etc, filesystem, and
> the device numbers are zero, when they shouldn't be.
> 
> And in fact, you can see that in the /proc/self/maps output that John showed
> in his first message:
> 
> 00008000-00106000 r-xp 00000000 00:00 8773       /bin/busybox
> 0010e000-0010f000 rw-p 000fe000 00:00 8773       /bin/busybox
> 0010f000-00111000 rw-p 00000000 00:00 0          [heap]
> b6dae000-b6eea000 r-xp 00000000 00:00 8937       /lib/libc-2.13.so
>                                 ^^^^^
>                                  dev & ino are always zero
> 
> So John, what's with the filesystem that you installed Valgrind on?
> 
> J
> 
> 
> 
> ----------------------------------------------------------------------------
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your
> own process in accordance with the BPMN 2 standard Learn Process modeling
> best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
>