valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Valgrind-users Digest, Vol 92, Issue 3

[Vasily G. <vas...@gm...>]

Hello, David.

Sorry for inconvenience, but I simply haven't enough time to look in
this problem deeply.
FYI: My first investigation showed that it is necessary to do some
more efforts in VEX code to support these instructions.

Vasily

On Thu, Apr 3, 2014 at 12:23 AM, David Goldsmith <da...@ve...> wrote:
> Hi Vasily,
> I created a bug report (329963) back in January to address this shortcoming
> but I notice two months later that it hasn't been looked at.
> Just curious if it has been passed over or just very low priority?
> Thanks
>  -- David
>
>
> On Thu, Jan 9, 2014 at 5:34 PM,
> <val...@li...> wrote:
>>
>> Mr. Goldsmith,
>>
>> Yes, now Valgrind doesn't know VCVBT and VCVTT instructiosn on ARM.
>> So, please, create bug in bug-tracker. For reproducing it is better to
>> use "__asm__ __volatile__ (...)".
>> I'll try to go deeper in VEX library and if it is successfully -
>> produce patch and attach it to the bug. In any case, for me it is not
>> an issue for 1-2 hours, unfortunately.
>>
>> Vasily
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] Valgrind-users Digest, Vol 92, Issue 3

[David G. <da...@ve...>]

Hi Vasily,
I created a bug report (329963) back in January to address this shortcoming
but I notice two months later that it hasn't been looked at.
Just curious if it has been passed over or just very low priority?
Thanks
 -- David


On Thu, Jan 9, 2014 at 5:34 PM, <
val...@li...> wrote:

> Mr. Goldsmith,
>
> Yes, now Valgrind doesn't know VCVBT and VCVTT instructiosn on ARM.
> So, please, create bug in bug-tracker. For reproducing it is better to
> use "__asm__ __volatile__ (...)".
> I'll try to go deeper in VEX library and if it is successfully -
> produce patch and attach it to the bug. In any case, for me it is not
> an issue for 1-2 hours, unfortunately.
>
> Vasily
>

Re: [Valgrind-users] mpich unable to munmap hugepages

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

On Wed, 2014-04-02 at 07:17 -0700, janjust wrote:
> ah ok so this is a virtual filesystem or something, I'm still unsure what is
> going on.
> the example you provided succeeds for me as well, but...this file:
> 
> > /var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.26201.kvs_4761352
> Doesn't exist or something else is going on…
Yes, this file is created when needed, and then unlinked.
See the trace produced by valgrind --trace-syscalls=yes ...

> 
> $ls /var/lib doesn't show hugetlbfs from my launch node, but it shows up if
> I run the $ls /var/lib by launching the job with $aprun it evaluates to: 
Not knowing what is aprun and what it does, I have no idea why it helps
to "see" the mounted hugetlbfs file system.

> 
> janjust@titan-batch7:~/janjust_proj/tmp$ aprun -n 1 -N 1 ls -lah
> /var/lib/hugetlbfs/global/
> Couldn't parse executable
> total 0
> drwxr-xr-x 8 root root 160 Apr  1 13:45 .
> drwxr-xr-x 3 root root  60 Apr  1 13:45 ..
> drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-131072
> drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-16777216
> drwxrwxrwt 2 root root   0 Apr  2 09:52 pagesize-2097152
> drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-524288
> drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-67108864
> drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-8388608
> 
> but then "pagesize-2097152" is empty, which could be why the call is
> failing…
I do not think the failure is linked to the 0 size.
The small executable works with a 0 size 4m.txt
(just remove the unlink from the small test program, and you will
see that 4m.txt is created if needed, and then mapped).
Relaunching works even if the 4m.txt has a 0 size.

What might be the problem is bad/wrong support of huge pages by
Valgrind. I know very little about huge pages, but it looks like
the below pagesize-xxxxx indicates to map a huge page of the size.
It looks like you ask for a 4M huge page but on the pagesize-2097152.


Maybe you could update the small program to do exactly the same open
and same mmap, but with the absolute patch name of the file
in the hugetbls stuff ?
Then run it natively (I am assuming this should work, including with the
hugetbls)
Then run it under strace
Then run it under valgrind
Then run it under strace -f valgrind
We might see the difference in the way the underlying mmap calls are
done.

(you might have to do all that under aprun
(maybe you can do aprun bash or something like that)

Philippe

> 
> 
> 
> 
> --
> View this message in context: http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-tp49150p49168.html
> Sent from the Valgrind - Users mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] mpich unable to munmap hugepages

[janjust <tja...@un...>]

ah ok so this is a virtual filesystem or something, I'm still unsure what is
going on.
the example you provided succeeds for me as well, but...this file:

> /var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.26201.kvs_4761352
Doesn't exist or something else is going on…

$ls /var/lib doesn't show hugetlbfs from my launch node, but it shows up if
I run the $ls /var/lib by launching the job with $aprun it evaluates to: 

janjust@titan-batch7:~/janjust_proj/tmp$ aprun -n 1 -N 1 ls -lah
/var/lib/hugetlbfs/global/
Couldn't parse executable
total 0
drwxr-xr-x 8 root root 160 Apr  1 13:45 .
drwxr-xr-x 3 root root  60 Apr  1 13:45 ..
drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-131072
drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-16777216
drwxrwxrwt 2 root root   0 Apr  2 09:52 pagesize-2097152
drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-524288
drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-67108864
drwxrwxrwt 2 root root   0 Apr  1 13:45 pagesize-8388608

but then "pagesize-2097152" is empty, which could be why the call is
failing…




--
View this message in context: http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-tp49150p49168.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] mpich unable to munmap hugepages

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

On Mon, 2014-03-31 at 14:43 -0700, janjust wrote:
> (hm my direct reply seems to be getting rejected)
> 
> Yes,
> The output is rather large so I attached 3 files that were the result of
> running it with 2 procs. 1 for stdout and the other two are from
> --log-file=valgrind.%p
> -Tommy
> 
> val.out <http://valgrind.10908.n7.nabble.com/file/n49155/val.out>  
> 
> valgrind.26200
> <http://valgrind.10908.n7.nabble.com/file/n49155/valgrind.26200>  
> 
> valgrind.26269
> <http://valgrind.10908.n7.nabble.com/file/n49155/valgrind.26269>  

Looking at the output, this seems to be the relevant trace:

SYSCALL[26201,1](  2) sys_open ( 0x5ec9cc(/proc/mounts), 0 ) --> [async] ... 
SYSCALL[26201,1](  2) ... [async] --> Success(0x0:0x11) 
SYSCALL[26201,1](  5) sys_newfstat ( 17, 0xffebf76e0 )[sync] --> Success(0x0:0x0) 
SYSCALL[26201,1](  9) sys_mmap ( 0x0, 4096, 3, 34, -1, 0 ) --> [pre-success] Success(0x0:0x4e71000) 
SYSCALL[26201,1](  0) sys_read ( 17, 0x4e71000, 1024 ) --> [async] ... 
SYSCALL[26201,1](  0) ... [async] --> Success(0x0:0x400) 
SYSCALL[26201,1](137) sys_statfs ( 0xffebfaa85(/var/lib/hugetlbfs/global/pagesize-2097152), 0xffebf9a80 )[sync] --> Success(0x0:0x0) 
SYSCALL[26201,1](  3) sys_close ( 17 )[sync] --> Success(0x0:0x0) 
SYSCALL[26201,1]( 11) sys_munmap ( 0x4e71000, 4096 )[sync] --> Success(0x0:0x0) 
SYSCALL[26201,1](  2) sys_open ( 0xffebf8a80(/var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.26201.kvs_4761352), 66, 493 ) --> [async] ... 
SYSCALL[26201,1](  2) ... [async] --> Success(0x0:0x11) 
SYSCALL[26201,1]( 87) sys_unlink ( 0xffebf8a80(/var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.26201.kvs_4761352) ) --> [async] ... 
SYSCALL[26201,1]( 87) ... [async] --> Success(0x0:0x0) 
SYSCALL[26201,1](  9) sys_mmap ( 0x0, 4194304, 3, 1, 17, 0 ) --> [pre-fail] Failure(0x16) 

I then tried to reproduce the problem above with the small below
code, doing exactly the same syscalls with same parameter,
except the fd arg to mmap, which must be the result of the open.
The below works on my system.
You could try the below (natively and under valgrind) and see
if that fails or not.
If that does not fail, then you should replace 4m.txt with a path
name similar to the above (assuming the path
/var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.26201.kvs_4761352
is on a "strangely mounted" filesystem cfr the open /proc/mounts just
above).
If the below (and the modified below) succeeds, but the mpich run
fails, then I guess you will be obliged to debug the valgrind code
itself, to see what exactly makes the syscall fail with EINVAL:
  is it the valgrind checks ?
  or is it the real syscall failing ?
Rather than debugging Valgrind, you might first try to find if the
syscall itself fails  by running valgrind under strace e.g.
  strace -f valgrind mmap_huge

Philippe

#include <stdio.h>
#include <sys/mman.h>
main()
{
  int fd;
  char *m;
  fd = open("4m.txt",  66, 493 );
  printf ("open result : %d\n", fd);
  unlink ("4m.txt");
  m = (char*) mmap ( 0x0, 4194304, 3, 1, fd, 0 );
  printf ("mmap result %p\n", m);
}

Re: [Valgrind-users] mpich unable to munmap hugepages

[janjust <tja...@un...>]

(hm my direct reply seems to be getting rejected)

Yes,
The output is rather large so I attached 3 files that were the result of
running it with 2 procs. 1 for stdout and the other two are from
--log-file=valgrind.%p
-Tommy

val.out <http://valgrind.10908.n7.nabble.com/file/n49155/val.out>  

valgrind.26200
<http://valgrind.10908.n7.nabble.com/file/n49155/valgrind.26200>  

valgrind.26269
<http://valgrind.10908.n7.nabble.com/file/n49155/valgrind.26269>  



--
View this message in context: http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-tp49150p49155.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] mpich unable to munmap hugepages

[<fd0...@sk...>]

> Le 31 mars 2014 à 22:01, janjust <tja...@un...> a écrit :
>
>
> Thanks for replying!
> The entire program output is at the bottom.
>
> The error is:
> Unable to mmap hugepage 4194304 bytes
> Unable to mmap hugepage 4194304 bytes
Can you run with --trace-syscalls=yes -v -v -v -d -d- d
to have more info about what is happening ?

Philippe

Re: [Valgrind-users] mpich unable to munmap hugepages

[janjust <tja...@un...>]

Thanks for replying!
The entire program output is at the bottom.

The error is:
Unable to mmap hugepage 4194304 bytes
Unable to mmap hugepage 4194304 bytes

This is surely mpich specific , as ompi works just fine.
The application is very simple, just a simple hello-world example with
MPI_Init, send/receive, gather, barrier.

My valgrind version is from trunk; however, this happens with the 3.9
release too which is the latest stable I'm guessing.

OS is Cray's compute node linux - 64bit
uname -a gives: 
Linux xxxx-ext1 2.6.32.59-0.7-default #1 SMP 2012-07-13 15:50:56 +0200
x86_64 x86_64 x86_64 GNU/Linux

Btw, I ran pretty large scientific codes with valgrind without a problem,
the major issues are typically non-handled instructions which can be omitted
from time to time with compiler flags. Memory was never an issue.

=============
janjust@login8:~/janjust_proj/tmp$ aprun -n 2 -N 1
../valgrind-trunk-build/bin/valgrind --tool=none ./a.out
==16936== Nulgrind, the minimal Valgrind tool
==20916== Nulgrind, the minimal Valgrind tool
==16936== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==20916== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==16936== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
info
==16936== Command: ./a.out
==20916== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright
info
==20916== Command: ./a.out
==16936==
==20916==
Unable to mmap hugepage 4194304 bytes
Unable to mmap hugepage 4194304 bytes
For file
/var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.16937.kvs_4760754
err Invalid argument
For file
/var/lib/hugetlbfs/global/pagesize-2097152/hugepagefile.MPICH.0.20917.kvs_4760754
err Invalid argument
Rank 1 [Mon Mar 31 15:45:07 2014] [c0-0c0s1n0] Fatal error in MPI_Init:
Other MPI error, error stack:
MPIR_Init_thread(449).............:
MPID_Init(234)....................: channel initialization failed
MPIDI_CH3_Init(83)................:
MPID_nem_init(325)................:
MPID_nem_gni_init(1695)...........:
MPID_nem_gni_dma_buffers_init(769): Out of memory
Rank 0 [Mon Mar 31 15:45:07 2014] [c0-0c0s1n3] Fatal error in MPI_Init:
Other MPI error, error stack:
MPIR_Init_thread(449).............:
MPID_Init(234)....................: channel initialization failed
MPIDI_CH3_Init(83)................:
MPID_nem_init(325)................:
MPID_nem_gni_init(1695)...........:
MPID_nem_gni_dma_buffers_init(769): Out of memory
==16937==
==20917==
_pmiu_daemon(SIGCHLD): [NID 00093] [c0-0c0s1n3] [Mon Mar 31 15:45:07 2014]
PE RANK 0 exit signal Killed
_pmiu_daemon(SIGCHLD): [NID 00002] [c0-0c0s1n0] [Mon Mar 31 15:45:07 2014]
PE RANK 1 exit signal Killed
==16936==
==20916==
[NID 00093] 2014-03-31 15:45:07 Apid 4760754: initiated application
termination
Application 4760754 exit codes: 137
Application 4760754 resources: utime ~0s, stime ~0s, Rss ~28836, inblocks
~10526, outblocks ~54958
==============







--
View this message in context: http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-tp49150p49153.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

[Valgrind-users] Floating points flags

[Domingues L. F. <Lui...@ed...>]

Hello,

For a tool I'm building, I want to have access to the floating points
exception flags (fenv.h).  It is possible to do this easily? Because
when I try to compile with C99 I have compilation errors.

Regards,
Luis Domingues

Re: [Valgrind-users] mpich unable to munmap hugepages

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

On Mon, 2014-03-31 at 07:23 -0700, janjust wrote:
> Hi,
Hello,

>    I'm trying to run a cray-mpich mpi application under valgrind; however,
> I'm getting an error message from mpich that it cannot unmap/remap huge
> pages.
What error msg do you get ?

> Did anyone encounter this problem before? Any workarounds?
Valgrind significantly increases the memory usage, and manages
the address space itself (and differently from a native run).

Which version of Valgrind are you using on which OS ?
32 or 64 bits ?

I suggest to start valgrind with various tracing options
to see what happens e.g. 
   --trace-syscalls=yes -v -v -v -d -d -d
and observe the traces around the mpich error msg

Philippe

[Valgrind-users] mpich unable to munmap hugepages

[janjust <tja...@un...>]

Hi,
   I'm trying to run a cray-mpich mpi application under valgrind; however,
I'm getting an error message from mpich that it cannot unmap/remap huge
pages.
Did anyone encounter this problem before? Any workarounds?

Thanks!



--
View this message in context: http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-tp49150.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Fwd: Odd Error Message

[Mike F. <goo...@gm...>]

Thanks Tom,

You just confirmed what I have been researching..
Apparently this program grabs a few tidbits from the command line to make
it's config file name and seems to grab the execution path for where to
look for it.
Looks like I have a bit of work to do before I can run Valgrind on it.

Thanks again

Mike


On Wed, Mar 26, 2014 at 3:44 PM, Tom Hughes <to...@co...> wrote:

> On 26/03/14 21:08, Mike Finneran wrote:
>
>  I'm new to Valgrind, but I've used Valgrind to debug new/delete problems
>> of a few small C++ programs(a few thousand lines of code), but now I'm
>> trying to debug a larger one (60K+ lines of code) and I'm getting an
>> apparently unusual error message.
>>
>> When I give the command:
>> GSlice=allways-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck
>> --leak-check=full --num-callers=40 --log-file=valgrind.log ./l2a
>> ../bdti/DSP_w_vec.bc
>>
>> I get the output:
>> Filename: /usr/bin/valgrdefault.conf
>> FATAL ERROR: config::parse(): File open failed
>>
>> I can't seem to find any reference to valgrdefault.conf on the Net of in
>> the Docs.
>>
>
> That's not a message from valgrind - it will be a message from your
> program.
>
> At a guess it is doing something "clever" by taking argv[0] something in
> /proc that points to the path of the current executable and and trying to
> modify it to point to a config file and getting confused by the fact that
> it is the path to valgrind rather than it's path.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] Fwd: Odd Error Message

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

On 26/03/14 21:08, Mike Finneran wrote:

> I'm new to Valgrind, but I've used Valgrind to debug new/delete problems
> of a few small C++ programs(a few thousand lines of code), but now I'm
> trying to debug a larger one (60K+ lines of code) and I'm getting an
> apparently unusual error message.
>
> When I give the command:
> GSlice=allways-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck
> --leak-check=full --num-callers=40 --log-file=valgrind.log ./l2a
> ../bdti/DSP_w_vec.bc
>
> I get the output:
> Filename: /usr/bin/valgrdefault.conf
> FATAL ERROR: config::parse(): File open failed
>
> I can't seem to find any reference to valgrdefault.conf on the Net of in
> the Docs.

That's not a message from valgrind - it will be a message from your program.

At a guess it is doing something "clever" by taking argv[0] something in 
/proc that points to the path of the current executable and and trying 
to modify it to point to a config file and getting confused by the fact 
that it is the path to valgrind rather than it's path.

Tom

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

[Valgrind-users] Fwd: Odd Error Message

[Mike F. <goo...@gm...>]

Hi
I'm new to Valgrind, but I've used Valgrind to debug new/delete problems of
a few small C++ programs(a few thousand lines of code), but now I'm trying
to debug a larger one (60K+ lines of code) and I'm getting an apparently
unusual error message.

When I give the command:
GSlice=allways-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck
--leak-check=full --num-callers=40 --log-file=valgrind.log ./l2a
../bdti/DSP_w_vec.bc

I get the output:
Filename: /usr/bin/valgrdefault.conf
FATAL ERROR: config::parse(): File open failed

I can't seem to find any reference to valgrdefault.conf on the Net of in
the Docs.

Any Ideas?

Thanks
Mike

Re: [Valgrind-users] Syscall/ioctl wrappers

[Subhashish P. <sp...@gm...>]

On Mon, Mar 24, 2014 at 3:15 PM, Tom Hughes <to...@co...> wrote:
> On 24/03/14 09:37, Subhashish Pradhan wrote:
>
>> 1 - It was mentioned "it may well be that no memory is read/written,
>> but you'd have to look at the kernel and see what that ioctl does to
>> be sure." Does it mean using strace or looking at kernel logs using
>> dmesg?
>
>
> It means reading the kernel source to see what that ioctl does and what
> memory it accesses.

...

> Porting valgrind to a new platform is a major undertaking so you really need
> to start by reading the code carefully and understanding it all works. If
> you try and understand it by asking questions about every little detail here
> it will be very painful...
>

...

> All that should have been pretty obvious from reading one of them though,
> which is exactly what I just had to do to answer your question, as they have
> lots of comments in explaining what is going on.
>
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/


I think I'd have to really go through the source and work them out
rather than getting the gist from documentation and stopping there.

But may I come back here to ask about the correctness of an
implementation or patch in future if I'm able to do that?

Regards,
Subhashish Pradhan

Re: [Valgrind-users] Syscall/ioctl wrappers

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

On 24/03/14 09:37, Subhashish Pradhan wrote:

> 1 - It was mentioned "it may well be that no memory is read/written,
> but you'd have to look at the kernel and see what that ioctl does to
> be sure." Does it mean using strace or looking at kernel logs using
> dmesg?

It means reading the kernel source to see what that ioctl does and what 
memory it accesses.

> 2 - These ARG1, ARG2 and ARG3 in that source - what's their relation
> to the syscall that's being wrapped?

They are the system call arguments.

> 3 - The PRINT(), PRE_MEM_READ(), PRE_REG_READ(), POST_MEM_WRITE  -
> where in the source is their definition? I need to understand what
> they do - I get the context that they are the read/write primitives of
> valgrind or am I wrong here?

Well PRINT prints a message and the others tell valgrind what registers 
and/or memory the system call is going to read/write so that it can 
check that things that will be read are initialised, and mark things 
which are written as initialised.

> 4 - I would be  porting valgrind to GNUMach based Hurd - so I'd have
> to handle RPCs there, so basically I'd need to implement
> syswrap-platform.c, and maybe syscall-platform.S, am I right?

Porting valgrind to a new platform is a major undertaking so you really 
need to start by reading the code carefully and understanding it all 
works. If you try and understand it by asking questions about every 
little detail here it will be very painful...

> 5 - What's the speciality about the syscall-platform.S - why's it so
> "magical" as referred in syswrap-main.c?

Because it has to understand exactly how a system call happens on the 
platform, how to setup the arguments and make the call and collect the 
result, all the while making any registers which may be trampled on are 
saved, that the signal state is manipulated correctly and so on.

All that should have been pretty obvious from reading one of them 
though, which is exactly what I just had to do to answer your question, 
as they have lots of comments in explaining what is going on.

Tom

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

Re: [Valgrind-users] Syscall/ioctl wrappers

[Subhashish P. <sp...@gm...>]

Hello again!

Ok when I add case 0x5309: at line 5500 and build valgrind again and
run the eject under it, it gives me this:

sprkv5@cb-4440s:~$ valgrind ./eject
==29522== Memcheck, a memory error detector
==29522== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==29522== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==29522== Command: ./eject
==29522==
==29522==
==29522== HEAP SUMMARY:
==29522==     in use at exit: 0 bytes in 0 blocks
==29522==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==29522==
==29522== All heap blocks were freed -- no leaks are possible
==29522==
==29522== For counts of detected and suppressed errors, rerun with: -v
==29522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

But I have some more questions -

1 - It was mentioned "it may well be that no memory is read/written,
but you'd have to look at the kernel and see what that ioctl does to
be sure." Does it mean using strace or looking at kernel logs using
dmesg?

2 - These ARG1, ARG2 and ARG3 in that source - what's their relation
to the syscall that's being wrapped?

3 - The PRINT(), PRE_MEM_READ(), PRE_REG_READ(), POST_MEM_WRITE  -
where in the source is their definition? I need to understand what
they do - I get the context that they are the read/write primitives of
valgrind or am I wrong here?

4 - I would be  porting valgrind to GNUMach based Hurd - so I'd have
to handle RPCs there, so basically I'd need to implement
syswrap-platform.c, and maybe syscall-platform.S, am I right?

5 - What's the speciality about the syscall-platform.S - why's it so
"magical" as referred in syswrap-main.c?

Regards,
Subhashish Pradhan


On Mon, Mar 24, 2014 at 2:10 PM, Tom Hughes <to...@co...> wrote:
> On 24/03/14 07:09, Subhashish Pradhan wrote:
>
>> The eject.c example provided here at http://leapster.org/linux/cdrom/
>> will compile successfuly
>> with a #include <stdlib.h>. Then when run it under as "valgrind
>> ./eject', it still reports:
>>
>> ==6212== Command: ./eject
>> ==6212==
>> ==6212== Warning: noted but unhandled ioctl 0x5309 with no size/direction
>> hints
>> ==6212==    This could cause spurious value errors to appear.
>> ==6212==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
>> writing a proper wrapper.
>>
>> Why would that be? (since ioctls are wrapped in
>> coregrind/m_syswrap/syswrap-linux.c)
>
>
> The ioctl system call in general is wrapped, but it doesn't know about every
> single ioctl, so you may need to teach it. If you read the file it mentions
> in the message you will find some hints, especially in the final section
> about ioctls.
>
>
>> What is this "ioctl 0x5309 with no size/redirection hints" and how
>> could that be solved
>> by PRE or POST functions?
>
>
> Because the ioctl number can encode the size and direction of memory access
> valgrind can sometimes guess at how much memory will be read or written by a
> system call.
>
> Not all ioctls actually make use of that facility though, and even when they
> do it may not be right, so valgrind has specific wrappers for many ioctls to
> make sure we do the right thing.
>
>
>> Or specifically, I couldn't understand the 0x5309 operation code
>> context as explained in this post on this mailing list below:
>>
>> <http://valgrind.10908.n7.nabble.com/noted-but-unhandled-ioctl-0xae03-with-no-size-direction-hints-tp38957p38959.html>
>
>
> Add it to the switch statement in the ioctl wrappers, with appropriate calls
> to indicate how much memory is read/written.
>
> In this case, and assuming that ioctl triggers the eject, it may well be
> that no memory is read/written, but you'd have to look at the kernel and see
> what that ioctl does to be sure.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/

Re: [Valgrind-users] Syscall/ioctl wrappers

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

On 24/03/14 07:09, Subhashish Pradhan wrote:

> The eject.c example provided here at http://leapster.org/linux/cdrom/
> will compile successfuly
> with a #include <stdlib.h>. Then when run it under as "valgrind
> ./eject', it still reports:
>
> ==6212== Command: ./eject
> ==6212==
> ==6212== Warning: noted but unhandled ioctl 0x5309 with no size/direction hints
> ==6212==    This could cause spurious value errors to appear.
> ==6212==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
> writing a proper wrapper.
>
> Why would that be? (since ioctls are wrapped in
> coregrind/m_syswrap/syswrap-linux.c)

The ioctl system call in general is wrapped, but it doesn't know about 
every single ioctl, so you may need to teach it. If you read the file it 
mentions in the message you will find some hints, especially in the 
final section about ioctls.

> What is this "ioctl 0x5309 with no size/redirection hints" and how
> could that be solved
> by PRE or POST functions?

Because the ioctl number can encode the size and direction of memory 
access valgrind can sometimes guess at how much memory will be read or 
written by a system call.

Not all ioctls actually make use of that facility though, and even when 
they do it may not be right, so valgrind has specific wrappers for many 
ioctls to make sure we do the right thing.

> Or specifically, I couldn't understand the 0x5309 operation code
> context as explained in this post on this mailing list below:
> <http://valgrind.10908.n7.nabble.com/noted-but-unhandled-ioctl-0xae03-with-no-size-direction-hints-tp38957p38959.html>

Add it to the switch statement in the ioctl wrappers, with appropriate 
calls to indicate how much memory is read/written.

In this case, and assuming that ioctl triggers the eject, it may well be 
that no memory is read/written, but you'd have to look at the kernel and 
see what that ioctl does to be sure.

Tom

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

[Valgrind-users] Syscall/ioctl wrappers

[Subhashish P. <sp...@gm...>]

Hello!

I posted this on valgrind-devel mailing list but got no reply so i'm
posting it here.

I have some new questions that I'd like to understand about
unimplemented system calls.

The eject.c example provided here at http://leapster.org/linux/cdrom/
will compile successfuly
with a #include <stdlib.h>. Then when run it under as "valgrind
./eject', it still reports:

==6212== Command: ./eject
==6212==
==6212== Warning: noted but unhandled ioctl 0x5309 with no size/direction hints
==6212==    This could cause spurious value errors to appear.
==6212==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.

Why would that be? (since ioctls are wrapped in
coregrind/m_syswrap/syswrap-linux.c)

What is this "ioctl 0x5309 with no size/redirection hints" and how
could that be solved
by PRE or POST functions?

Or specifically, I couldn't understand the 0x5309 operation code
context as explained in this post on this mailing list below:
<http://valgrind.10908.n7.nabble.com/noted-but-unhandled-ioctl-0xae03-with-no-size-direction-hints-tp38957p38959.html>

How can we use that opcode to write wrappers?

Regards,
Subhashish Pradhan

Re: [Valgrind-users] Dirty calls

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

On 03/22/2014 08:51 AM, Domingues Luis Filipe wrote:
> Hello,
> 
> I'm using dirty-calls on a tool I'm building. And I want to know what's
> the limitations of the parameters for dirty-calls (Types, how many...)

The answer depends on the architecture you're using. E.g. for x86-64 you
may pass up to 6 arguments; for s390 you may pass up to 5. In general,
minimising the number of arguments of a helper call is a good idea
because instruction selection will often generate register-to-register
moves for the arguments and the register allocator does not do a very
good job throwing them out.
Take a look at VEX/priv/host_ARCH_isel.c to find out what is allowed for
the architecture you have in mind. Search for Ist_Dirty.
AFAIK only integer arguments are allowed.

   Florian

[Valgrind-users] Dirty calls

[Domingues L. F. <Lui...@ed...>]

Hello,

I'm using dirty-calls on a tool I'm building. And I want to know what's
the limitations of the parameters for dirty-calls (Types, how many...)

I'm using Valgrind 3.9

Regards,
Luis Domingues.

Re: [Valgrind-users] Valgrind on ARM embedded system

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

On 03/21/2014 03:15 AM, Giuseppe Assalve wrote:

> I've installed Valgrind and I've added debug info to my libc.

Please tell us which CPU architecture and variant, chip manufacturer, and model name.
Please tell us which operating system, distribution brand name, and version number.
Please tell us which libc (glibc, dietlibc, uClibc, bionic, ...) and version number.
Please start a new newsgroup posting thread unless the content of your post
is a direct reply to an existing conversation.
Else there is little incentive to pay any attention to your report.

Re: [Valgrind-users] Valgrind on ARM embedded system

[Giuseppe A. <giu...@sa...>]

Hello,

I've installed Valgrind and I've added debug info to my libc.

But now, each time I try to launch Valgrind I have the following error:

/*root@mx27:/usr/local/lib/valgrind# valgrind ls -la*//*
*//*==1486== Memcheck, a memory error detector*//*
*//*==1486== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et 
al.*//*
*//*==1486== Using Valgrind-3.9.0 and LibVEX; rerun with -h for 
copyright info*//*
*//*==1486== Command: ls -la*//*
*//*==1486== *//*
*//*==1486== *//*
*//*==1486== Process terminating with default action of signal 4 
(SIGILL)*//*
*//*==1486==  Illegal opcode at address 0x3807BD5C*//*
*//*==1486==    at 0x4000800: ??? (in /lib/ld-2.6.1.so)*//*
*//*
*//*valgrind: m_scheduler/scheduler.c:957 (run_thread_for_a_while): 
Assertion 'done_this_time >= 0' failed.*//*
*//*==1486==    at 0x38034C18: report_and_quit (m_libcassert.c:260)*//*
*//*==1486==    by 0x624A9AAF: ???*//*
*//*
*//*sched status:*//*
*//*  running_tid=1*//*
*//*
*//*Thread 1: status = VgTs_Runnable*//*
*//*==1486==    at 0x4000800: ??? (in /lib/ld-2.6.1.so)*/

...any idea?
Thanks


Il 19/03/2014 21:02, Philippe Waroquiers ha scritto:
> On Wed, 2014-03-19 at 13:50 +0000, Tom Hughes wrote:
>> On 19/03/14 12:45, Ashoka K wrote:
>>    on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled.
>>> I tested and found that summary of valgrind output is shown only on
>>> graceful exit of
>>> the application. Tested with a small memleak program as described in Valgrind
>>> documentation.
>> Memory leaks are only reported when the program finishes, unless you use
>> a client request to ask for a check.
> You can also trigger leak check from shell script (or from gdb),
> using vgdb.
>
> e.g.   vgdb leak_check full possible increased
> will do a leak check, showing the possibly and definitely leaked loss
> records that have increased since the previous leak check.
>
> Philippe
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind on ARM embedded system

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

On Wed, 2014-03-19 at 13:50 +0000, Tom Hughes wrote:
> On 19/03/14 12:45, Ashoka K wrote:
>   on the device. Device is ARM OMAP running Linux-2.6.33 cross compiled.
> >
> > I tested and found that summary of valgrind output is shown only on
> > graceful exit of
> > the application. Tested with a small memleak program as described in Valgrind
> > documentation.
> 
> Memory leaks are only reported when the program finishes, unless you use 
> a client request to ask for a check.

You can also trigger leak check from shell script (or from gdb),
using vgdb.

e.g.   vgdb leak_check full possible increased
will do a leak check, showing the possibly and definitely leaked loss
records that have increased since the previous leak check.

Philippe

Re: [Valgrind-users] Valgrind on ARM embedded system

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

> Is there any way to check the the summary of Valgrind found issues while
> application is still running ...

Look in memcheck/memcheck.h and search for all instances of LEAK_CHECK.
The app should catch a signal and the handler should call one of
the LEAK_CHECK requests.  Or, make a suitable LEAK_CHECK call
synchronously at appropriate times: just before and after
each "phase", or after every N events, etc.

--