valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

[Christian P. <chr...@gm...>]

2015-02-02 21:26 GMT+00:00 Philippe Waroquiers <
phi...@sk...>:

> On Mon, 2015-02-02 at 14:51 +0100, Josef Weidendorfer wrote:
> > Am 02.02.2015 um 12:49 schrieb Christian Priebe:
> > > The same line repeats until I shutdown vgdb. Ok, running "vgdb
> --pid=XXX
> > > v.wait 500" without any tool (i.e. "valgrind bin/mysqld")
> >
> > Without a tool specified, the default is memcheck.
> >
> > > So, apparently this has nothing to do with callgrind but with valgrind
> > > (or my setup) in general.
> >
> > Ok, perhaps Philippe has an idea what's going wrong.
>
> >From the vgdb traces, it looks like all is working at vgdb side,
> and that it is the valgrind side that does not properly replies
> back to vgdb.
>
> At this stage, I do not see too much what is going wrong.
> So, let's capture some more data.
>
> On what distro/platform/... are you running ?
>

Thanks again to both of you for helping! The "experiments" are run on 64bit
Ubuntu 14.04.


>
> Can you also do the following experiments ?
>
> 1. under your user account (so no sudo, etc), do
>       # in one window:
>       valgrind sleep 100
>       # then in another window
>       vgdb --pid=xxxxxx help
>    This last help command should output the list of commands supported
>    by valgrind gdbserver
>    If that does not work (i.e. vgdb blocks), redo the same but
>    giving   -v -v -v -d -d -d    options to valgrind
>    and      -d -d -d             option  to vgdb
>    and send the traces
>

Works fine.


>
> 2. If the above works, do the same operations, but with the technique
>    you use to launch mysql
>    IIUC, use sudo in one window to launch valgrind
>    and sudo in another window to launch vgdb
>    (I am not too sure what the --user=mysql option does/means for mysqld
>     so no idea if you can really simulate what that does easily).
>
>    Again, if that does not work, redo with the -v/-d args as above
>
>
Works fine. The --user=mysql option would result in mysqld being run under
the mysql user, but I haven't used this option in any of the recent test
runs so it shouldn't matter.


> 3. If the above works, then give options  -v/-d to
>    valgrind that runs mysql
>    and to the vgdb
>
> As suggested by Josef, you might create a bug in bugzilla so as to
> attach the traces (compressed if too big) of the first failing
> experiment.
>

I created a bug report here:

https://bugs.kde.org/show_bug.cgi?id=343715

Thanks
Christian


>
> Thanks
>
> Philippe
>
>
>

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

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

On Mon, 2015-02-02 at 14:51 +0100, Josef Weidendorfer wrote:
> Am 02.02.2015 um 12:49 schrieb Christian Priebe:
> > The same line repeats until I shutdown vgdb. Ok, running "vgdb --pid=XXX
> > v.wait 500" without any tool (i.e. "valgrind bin/mysqld")
> 
> Without a tool specified, the default is memcheck.
> 
> > So, apparently this has nothing to do with callgrind but with valgrind
> > (or my setup) in general.
> 
> Ok, perhaps Philippe has an idea what's going wrong.

>From the vgdb traces, it looks like all is working at vgdb side,
and that it is the valgrind side that does not properly replies
back to vgdb.

At this stage, I do not see too much what is going wrong.
So, let's capture some more data.

On what distro/platform/... are you running ?

Can you also do the following experiments ?

1. under your user account (so no sudo, etc), do
      # in one window:
      valgrind sleep 100
      # then in another window
      vgdb --pid=xxxxxx help
   This last help command should output the list of commands supported
   by valgrind gdbserver
   If that does not work (i.e. vgdb blocks), redo the same but
   giving   -v -v -v -d -d -d    options to valgrind
   and      -d -d -d             option  to vgdb
   and send the traces

2. If the above works, do the same operations, but with the technique
   you use to launch mysql
   IIUC, use sudo in one window to launch valgrind 
   and sudo in another window to launch vgdb
   (I am not too sure what the --user=mysql option does/means for mysqld
    so no idea if you can really simulate what that does easily).

   Again, if that does not work, redo with the -v/-d args as above

3. If the above works, then give options  -v/-d to 
   valgrind that runs mysql
   and to the vgdb

As suggested by Josef, you might create a bug in bugzilla so as to
attach the traces (compressed if too big) of the first failing
experiment.

Thanks

Philippe

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

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

Am 02.02.2015 um 12:49 schrieb Christian Priebe:
> The same line repeats until I shutdown vgdb. Ok, running "vgdb --pid=XXX
> v.wait 500" without any tool (i.e. "valgrind bin/mysqld")

Without a tool specified, the default is memcheck.

> So, apparently this has nothing to do with callgrind but with valgrind
> (or my setup) in general.

Ok, perhaps Philippe has an idea what's going wrong.

It is probably good if you could add a bug report.

Thanks,
Josef

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

[Christian P. <chr...@gm...>]

2015-02-02 10:42 GMT+00:00 Josef Weidendorfer <Jos...@gm...>:

> Am 02.02.2015 um 00:00 schrieb Christian Priebe:
> > I'm back to the previous issue that callgrind_control or more
> > specifically vgdb hangs. This is the output I get when running vgdb -d
> > ...
>
> Hmm. Then it looks like a hang in the vgdb handler in callgrind, but I
> have no idea why.
>
> Can you first check if the hang also appears with another callgrind
> request such as
> "vgdb --pid=XXX zero", and with another tool (e.g. none) and another vgdb
> request, like "vgdb --pid=XXX v.wait 500" ?
>
>
Ok, two observations regarding the zero and instrumentation requests. First
of all, the vgdb --pid=XXX zero request behaves the same as the ...
instrumentation on request. Second, I occasionally get a different debug
output from vgdb which looks like the following:

1422876588.712688 vgdb: using
/tmp/vgdb-pipe-from-vgdb-to-1800-by-root-on-???
/tmp/vgdb-pipe-to-vgdb-from-1800-by-root-on-???
/tmp/vgdb-pipe-shared-mem-vgdb-1800-by-root-on-???
1422876588.712838 opening /tmp/vgdb-pipe-from-vgdb-to-1800-by-root-on-???
write to pid
1422876588.712882 opened /tmp/vgdb-pipe-from-vgdb-to-1800-by-root-on-???
write to pid fd 4
1422876588.712915 writing write \003 to wake up len 1  notify: 1
1422876588.712998 opening /tmp/vgdb-pipe-to-vgdb-from-1800-by-root-on-???
read cmd result from pid
1422876588.712916 written_by_vgdb_before_sleep 0
seen_by_valgrind_before_sleep 0
1422876588.815261 written_by_vgdb_before_sleep 1
seen_by_valgrind_before_sleep 0
1422876588.917737 written_by_vgdb_before_sleep 1
seen_by_valgrind_before_sleep 1
1422876589.020165 written_by_vgdb_before_sleep 1
seen_by_valgrind_before_sleep 1
1422876589.120366 written_by_vgdb_before_sleep 1
seen_by_valgrind_before_sleep 1
...

The same line repeats until I shutdown vgdb. Ok, running "vgdb --pid=XXX
v.wait 500" without any tool (i.e. "valgrind bin/mysqld") results in the
same output as before:

...
1422877084.623194 getregs regs_bsz 216
1422877084.623215 getregs PTRACE_GETREGS
1422877084.623229 detected a working PTRACE_GETREGS
1422877084.623238 push bad_return return address ptrace_write_memory
1422877084.623248 Writing 0000000000000000 to 0x804792d18
1422877084.623329 setregs regs_bsz 216
1422877084.623338 setregs PTRACE_SETREGS
1422877084.623352 PTRACE_CONT to invoke
1422877084.623827 waitstopped waitpid status after PTRACE_CONT to invoke
before waitpid signal_expected 19


So, apparently this has nothing to do with callgrind but with valgrind (or
my setup) in general.


Thanks again,
Christian



> If that works, it would be interesting to see the last lines of
> Callgrind debug output
> with "... --ct-verbose=2 ..." (or 3...), but warning: this can be huge,
> and should be
> directed to a file (eg. with --log-file=XX).
>

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

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

Am 02.02.2015 um 00:00 schrieb Christian Priebe:
> I'm back to the previous issue that callgrind_control or more
> specifically vgdb hangs. This is the output I get when running vgdb -d
> ...

Hmm. Then it looks like a hang in the vgdb handler in callgrind, but I
have no idea why.

Can you first check if the hang also appears with another callgrind
request such as
"vgdb --pid=XXX zero", and with another tool (e.g. none) and another vgdb
request, like "vgdb --pid=XXX v.wait 500" ?

If that works, it would be interesting to see the last lines of
Callgrind debug output
with "... --ct-verbose=2 ..." (or 3...), but warning: this can be huge,
and should be
directed to a file (eg. with --log-file=XX).

Josef

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

[Christian P. <chr...@gm...>]

2015-02-01 20:54 GMT+00:00 Philippe Waroquiers <
phi...@sk...>:

> On Sun, 2015-02-01 at 20:39 +0000, Christian Priebe wrote:
>
> >
> > It unfortunately does not work. I receive the following message:
> >
> > "vgdb error: no FIFO found matching pid 5803"
> >
> >
> > "5803" is the pid as reported by vgdb -l.
>
> can you do
>     vgdb -d -d -d -l
> and then
>     vgdb -d -d -d --pid=12345 help
> (assuming 12345 is the pid of the mysql process).
> That should give detailed tracing about which FIFOs are found
> and/or tried by both vgdb commands.
>
> Note that you have to run vgdb in a context
> which is similar to the context of the process you
> are trying to contact.
> Typically, TMPDIR and the user launching vgdb must be the same
> as TMPDIR value and user of the process you are trying to contact.
>

Thanks! I actualy made a mistake and ran mysqld under a different user. I'm
back to the previous issue that callgrind_control or more specifically vgdb
hangs. This is the output I get when running vgdb -d -d -d -pid=...
instrumentation on I get the following output:

1422830987.435580 vgdb: using
/tmp/vgdb-pipe-from-vgdb-to-7052-by-root-on-???
/tmp/vgdb-pipe-to-vgdb-from-7052-by-root-on-???
/tmp/vgdb-pipe-shared-mem-vgdb-7052-by-root-on-???
1422830987.435677 opening /tmp/vgdb-pipe-from-vgdb-to-7052-by-root-on-???
write to pid
1422830987.435720 written_by_vgdb_before_sleep 0
seen_by_valgrind_before_sleep 0
1422830987.435720 opened /tmp/vgdb-pipe-from-vgdb-to-7052-by-root-on-???
write to pid fd 4
1422830987.435796 writing write \003 to wake up len 1  notify: 1
1422830987.435811 opening /tmp/vgdb-pipe-to-vgdb-from-7052-by-root-on-???
read cmd result from pid
1422830987.536904 written_by_vgdb_before_sleep 1
seen_by_valgrind_before_sleep 0
1422830987.638022 after sleep written_by_vgdb 1 seen_by_valgrind 0
invoked_written -1
1422830987.638111 attach to 'main' pid 7052
1422830987.638153 attach main pid PTRACE_ATTACH pid 7052
1422830987.638428 waitstopped attach main pid before waitpid
signal_expected 19
1422830987.638704 after waitpid pid 7052 p 7052 status 0x137f WIFSTOPPED 19
1422830987.639102 found tid 1 status VgTs_WaitSys lwpid 7052
...
1422830987.645251 getregs regs_bsz 216
1422830987.645275 getregs PTRACE_GETREGS
1422830987.645289 detected a working PTRACE_GETREGS
1422830987.645302 push bad_return return address ptrace_write_memory
1422830987.645315 Writing 0000000000000000 to 0x804390d18
1422830987.645395 setregs regs_bsz 216
1422830987.645409 setregs PTRACE_SETREGS
1422830987.645424 PTRACE_CONT to invoke
1422830987.645461 waitstopped waitpid status after PTRACE_CONT to invoke
before waitpid signal_expected 19

and then it stops doing anything.


Thanks,
Christian



>
> Philippe
>
>
>
>
>

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

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

On Sun, 2015-02-01 at 20:39 +0000, Christian Priebe wrote:

> 
> It unfortunately does not work. I receive the following message:
> 
> "vgdb error: no FIFO found matching pid 5803"
> 
> 
> "5803" is the pid as reported by vgdb -l.

can you do
    vgdb -d -d -d -l
and then
    vgdb -d -d -d --pid=12345 help
(assuming 12345 is the pid of the mysql process).
That should give detailed tracing about which FIFOs are found
and/or tried by both vgdb commands.

Note that you have to run vgdb in a context
which is similar to the context of the process you
are trying to contact.
Typically, TMPDIR and the user launching vgdb must be the same
as TMPDIR value and user of the process you are trying to contact.

Philippe

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

[Christian P. <chr...@gm...>]

Hi Josef,

thanks a lot for your reply!

2015-02-01 15:44 GMT+00:00 <val...@li...>:

>
> Date: Sat, 31 Jan 2015 21:50:35 +0100
> From: Josef Weidendorfer <Jos...@gm...>
> Subject: Re: [Valgrind-users] Enabling instrumentation with
>         callgrind_control not working
> To: val...@li...
> Message-ID: <54C...@gm...>
> Content-Type: text/plain; charset=windows-1252
>
> Am 31.01.2015 um 14:49 schrieb Christian Priebe:
> > Apparently callgrind_control hangs on a read system call waiting for
> > some output from vgdb.
>
> Since Valgrind 3.9 or 3.10, callgrind_control is just a wrapper around
> vgdb.
> When mysql is running under callgrind, just call "vgdb -l" (sudo as
> needed).
> This gives something like
>
>  use --pid=28503 for ...
>
> and then run "vgdb --pid=28503 help" to see the commands you can send
> to callgrind, e.g. "vgdb --pid=28503 instrumentation on".
>
> Does this work?
>

It unfortunately does not work. I receive the following message:

"vgdb error: no FIFO found matching pid 5803"

"5803" is the pid as reported by vgdb -l.


Thanks again,
Christian



>
> Josef
>
> > If I shudown callgrind_control it outputs the
> > following:
> >
> > "syscall failed: Interrupted system call
> > error opening /tmp/vgdb-pipe-to-vgdb-from-19680-by-root-on-??? read cmd
> > result from pid"
> >
> > The specified file does exist under /tmp. mysqld does not respond to
> > MySQL clients trying to connect to it while callgrind_control is in that
> > hanging state and once I shutdown callgrind_control mysqld shuts down as
> > well. Does anyone have an idea about what is going on exactly or what to
> > do to resolve this? Running callgrind on mysqld with instrumentation
> > enabled from the beginning works perfectly fine for me. The valgrind and
> > callgrind version used is 3.10.1.
> >
> >
> > Thanks in advance,
> >   Christian
>

Re: [Valgrind-users] How to make use of callgrind --cacheuse=yes ?

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

Hi Steve,

> I'm looking for a way to answer the question 'how much of a cache line did I 
> use before discarding it?'.
> 
> ...
> 
>  g++ matrix.cpp -O0 -g

For performance analysis, you always should work with optimized code,
ie. "-O2 -g"
(actually, that doesn't change the data layout, so AcCost/SpLoss will be
the same).
But it may show different source lines because of inlining.

I just tried it out: with "-O0", all of AcCostX and SpLossX is shown in
"Data::operator int() const", which makes sense, as this accesses the
matrix.

With "-O2", everything is in main, and the source code panel shows that
everything is attributed to the line 59 with "sum += vec[j]". This is what
you also expect, or?

>  valgrind --tool=callgrind --cacheuse=yes --instr-atstart=no ./a.out
> 
> The output shows a large value for AcCost1 because of the padding in the 
> Data struct,

Actually, I think it makes more sense to compare the "spatial loss metrices"
with the number of data loaded into a given cache, for example for L2,
compare 64*DLmr (this is the amount of data loaded from main memory, as
there
are DLmr read misses and one miss accounts for 64 bytes to load), and
SpLoss2
(should be SpLossL), which shows "how many bytes never were used before
evicted".

In kcachegrind / qcachegrind, you can add a new derived event type "DLmr64"
as being "64 DLmr", by using the context menu in the event type panel
("add new
event type").

In your case, "64 * DLmr" is 10 242 624, and SpLoss2 is 9 508 008. That is,
from the data loaded, 92% is never accesses. Which obviously is bad...

> but kcachegrind doesn't point me to the loop as the cause of
> loading that struct and using so little of it.

That is actually a missing feature, and has to do with the complexity of
implementing "inclusive" aggregation up the call stack for AcCost/SpLoss.
As you see, the flat profile has only "exclusive" costs. And then of course,
the call graph visulization is not existing, as it uses inclusive cost for
the graph edges as base.

With "-O2", this aggregation is not needed, and points to the loop :-)
With "-O0", it would work if implemented...

The complexity comes from the fact that the simulator can detect
AcCost/SpLoss
only at eviction time of the cacheline, but this cost gets related to
the access which loaded this lines into the cache (which makes sense in
my opinion).
Currently, when a cacheline is loaded, I only remember the corresponding
counters
which need to be updated afterwards, but for aggregation I need to also
remember the call stack, and update counters up the call stack at
cacheline eviction
time. No problem per se, but not implemented.

Actually, what I wanted to add at some point is miss/hit counters per data
structure, and this would give also better insight for AcCost/SpLoss.

> Is there something I'm missing here? Is the workflow of making use of the 
> option --cacheuse=yes different than I assume?

No. I hope above explains your observations...

Josef

PS: a padding of "64-sizeof(int)" is enough to see the same effect.

> 
> Thanks,
> 
> Steve.
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] How to make use of callgrind --cacheuse=yes ?

[Stephen K. <he...@st...>]

Hello,

I'm looking for a way to answer the question 'how much of a cache line did I 
use before discarding it?'.

I wrote this simple file 

 https://gist.github.com/steveire/7c3cfb0494b4708b68fe

and ran the following commands:

 g++ matrix.cpp -O0 -g
 valgrind --tool=callgrind --cacheuse=yes --instr-atstart=no ./a.out

The output shows a large value for AcCost1 because of the padding in the 
Data struct, but kcachegrind doesn't point me to the loop as the cause of 
loading that struct and using so little of it.

Is there something I'm missing here? Is the workflow of making use of the 
option --cacheuse=yes different than I assume?

Thanks,

Steve.

Re: [Valgrind-users] Enabling instrumentation with callgrind_control not working

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

Am 31.01.2015 um 14:49 schrieb Christian Priebe:
> Apparently callgrind_control hangs on a read system call waiting for
> some output from vgdb.

Since Valgrind 3.9 or 3.10, callgrind_control is just a wrapper around vgdb.
When mysql is running under callgrind, just call "vgdb -l" (sudo as needed).
This gives something like

 use --pid=28503 for ...

and then run "vgdb --pid=28503 help" to see the commands you can send
to callgrind, e.g. "vgdb --pid=28503 instrumentation on".

Does this work?

Josef

> If I shudown callgrind_control it outputs the
> following:
> 
> "syscall failed: Interrupted system call
> error opening /tmp/vgdb-pipe-to-vgdb-from-19680-by-root-on-??? read cmd
> result from pid"
> 
> The specified file does exist under /tmp. mysqld does not respond to
> MySQL clients trying to connect to it while callgrind_control is in that
> hanging state and once I shutdown callgrind_control mysqld shuts down as
> well. Does anyone have an idea about what is going on exactly or what to
> do to resolve this? Running callgrind on mysqld with instrumentation
> enabled from the beginning works perfectly fine for me. The valgrind and
> callgrind version used is 3.10.1.
> 
> 
> Thanks in advance,
>   Christian
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

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

On 31/01/15 15:07, Carl Ponder wrote:

> Grep'ing through the files in these directories
>
>     /usr/src/
>     /usr/include
>     /shared/apps/cuda/CUDA-v7.0.18
>     /shared/apps/rhel-6.2/tools/$USER/ValGrind-3.10.1
>
> I can't find anything that maps the address 30000001.
> Are these mappings only present for syscalls but not ioctl's?
> Or do we need to install a development version of the /usr/src files?

Well you won't normally find a raw ioctl number in the source because 
they are normally constructed with the _IO. _IOR, _IOW or _IOWR macros.

Specifically, and assuming this is amd64-linux, that number appears to 
correspond to:

   _IO(0x3000, 1)

But in all honest, given you presumably have the source to libcuda, the 
easiest thing will be just to look at that source to see what the ioctl 
is that is being called!

Tom

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

[Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Carl P. <cp...@nv...>]

I ran into this output from valgrind

    ==21898== Warning: noted but unhandled ioctl 0x30000001 with no
    size/direction hints.
    ==21898==   This could cause spurious value errors to appear.
    ==21898==   See README_MISSING_SYSCALL_OR_IOCTL for guidance on
    writing a proper wrapper.
    ==21898==   at 0x59C98C7: ioctl (in /lib64/libc-2.12.so)
    ==21898==   by 0x61D148D: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x62B7B94: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x6271A6F: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x61AE21C: cuInit (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x414D89: __pgi_uacc_cuda_init (cuda_init.c:225)
    ==21898==   by 0x408ACC: __pgi_uacc_enumerate (init.c:420)
    ==21898==   by 0x408E64: __pgi_uacc_initialize (init.c:580)
    ==21898==   by 0x405C09: __pgi_uacc_dataenterstart (dataenterstart.c:45)
    ==21898==   by 0x404A19: MAIN_ (test_synccheck.F:177)
    ==21898==   by 0x4027F3: main (in /home-2/cponder/Temp.064/synccheck)

I'd like to "gracefully" handle this ioctl in valgrind, and looked at 
the instructions posted here

    http://valgrind.org/docs/manual/dist.readme-missing.html

Grep'ing through the files in these directories

    /usr/src/
    /usr/include
    /shared/apps/cuda/CUDA-v7.0.18
    /shared/apps/rhel-6.2/tools/$USER/ValGrind-3.10.1

I can't find anything that maps the address 30000001.
Are these mappings only present for syscalls but not ioctl's?
Or do we need to install a development version of the /usr/src files?
Thanks,

                     Carl


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[Valgrind-users] Enabling instrumentation with callgrind_control not working

[Christian P. <chr...@gm...>]

Hi everyone!

I'm currently trying to run callgrind not on the whole program (mysqld in
my case) but just on a section of it/part of its execution. I therefore
start mysqld with the following command:

        sudo valgrind --tool=callgrind --instr-atstart=no
/usr/local/mysql/bin/mysqld --user=mysql

Unfortunately, when I then run the following to enable instrumentation
(after mysqld is up and running)

        sudo callgrind_control -i on

it justs prints out a message like this and that's it:

"PID 19680: bin/mysqld --user=mysql"

Apparently callgrind_control hangs on a read system call waiting for some
output from vgdb. If I shudown callgrind_control it outputs the following:

"syscall failed: Interrupted system call
error opening /tmp/vgdb-pipe-to-vgdb-from-19680-by-root-on-??? read cmd
result from pid"

The specified file does exist under /tmp. mysqld does not respond to MySQL
clients trying to connect to it while callgrind_control is in that hanging
state and once I shutdown callgrind_control mysqld shuts down as well. Does
anyone have an idea about what is going on exactly or what to do to resolve
this? Running callgrind on mysqld with instrumentation enabled from the
beginning works perfectly fine for me. The valgrind and callgrind version
used is 3.10.1.


Thanks in advance,
  Christian

[Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Carl P. <cp...@nv...>]

I ran into this output from valgrind

    ==21898== Warning: noted but unhandled ioctl 0x30000001 with no
    size/direction hints.
    ==21898==   This could cause spurious value errors to appear.
    ==21898==   See README_MISSING_SYSCALL_OR_IOCTL for guidance on
    writing a proper wrapper.
    ==21898==   at 0x59C98C7: ioctl (in /lib64/libc-2.12.so)
    ==21898==   by 0x61D148D: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x62B7B94: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x6271A6F: ??? (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x61AE21C: cuInit (in /usr/lib64/libcuda.so.346.29)
    ==21898==   by 0x414D89: __pgi_uacc_cuda_init (cuda_init.c:225)
    ==21898==   by 0x408ACC: __pgi_uacc_enumerate (init.c:420)
    ==21898==   by 0x408E64: __pgi_uacc_initialize (init.c:580)
    ==21898==   by 0x405C09: __pgi_uacc_dataenterstart (dataenterstart.c:45)
    ==21898==   by 0x404A19: MAIN_ (test_synccheck.F:177)
    ==21898==   by 0x4027F3: main (in /home-2/cponder/Temp.064/synccheck)

I'd like to "gracefully" handle this ioctl in valgrind, and looked at 
the instructions posted here

    http://valgrind.org/docs/manual/dist.readme-missing.html

Grep'ing through the files in these directories

    /usr/src/
    /usr/include
    /shared/apps/cuda/CUDA-v7.0.18
    /shared/apps/rhel-6.2/tools/$USER/ValGrind-3.10.1

I can't find anything that maps the address 30000001.
Are these mappings only present for syscalls but not ioctl's?
Or do we need to install a development version of the /usr/src files?
Thanks,

                     Carl


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[Valgrind-users] What is ioctl 0x30000001

[<ka...@il...>]

In my application I use OpenCV, although not the GPU and the program is 
strictly command line, anyways I hit a missing ioctl

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

Following the guide at 
http://valgrind.org/docs/manual/dist.readme-missing.html
I try
grep NNN /usr/include/asm/unistd*.h
Which didn't yield any results

Instead I took a look at my /usr/src/linux directory which in Gentoo 
points to the current kernel sources (/usr/src/linux-3.17.7-gentoo)

fruitcake@cortana /usr/src/linux $ grep -rin 0x30000001 .

./drivers/net/wireless/ath/ath6kl/core.h:212:#define 
AR6004_HW_1_1_VERSION                 0x30000001
./drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c:281: nv_wo32(base, 
0x94, 0x30000001);
./drivers/gpu/drm/nouveau/core/engine/fifo/nv50.c:246: 
nv_wo32(base->ramfc, 0x7c, 0x30000001);
./drivers/gpu/drm/nouveau/core/engine/fifo/nv50.c:310: 
nv_wo32(base->ramfc, 0x7c, 0x30000001);
./drivers/gpu/drm/nouveau/core/engine/fifo/nvc0.c:244: nv_wo32(base, 
0x94, 0x30000001);
./drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c:219: 
nv_wo32(base->ramfc, 0x7c, 0x30000001);
./drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c:292: 
nv_wo32(base->ramfc, 0x7c, 0x30000001);
./drivers/video/fbdev/pxa3xx-gcu.h:10:#define PXA3XX_GCU_SHARED_MAGIC  
0x30000001
./arch/arm/mach-cns3xxx/pm.c:66:        if (block & 0x30000001) {
./arch/powerpc/Kconfig.debug:294:         0x30000001 for your second one

I'm not really sure what I'm doing here, and I'm not a computer 
scientist by training, not familiar with OS internals.

Is the ioctl a call to 0x30000001 PXA3XX_GCU_SHARED_MAGIC? Anybody know 
of a fix to let me keep profiling, or maybe a way to see which line of 
source triggers the call?

Re: [Valgrind-users] Help: Can't make Valgrind executable.

[Azat K. <a3a...@gm...>]

On Thu, Jan 22, 2015 at 10:07:58PM +0100, Florian Krohm wrote:
> > ----- README
> > To install from a tar.bz2 distribution:
> > 
> >    4. Run ./configure, with some options if you wish.  The only interesting
> >       one is the usual --prefix=/where/you/want/it/installed.
> > 
> > ----- configure
> > ac_default_prefix=/usr/local

Also check you $PATH variable in bash:
$ echo $PATH

>From bash(1):
       PATH   The search path for commands.  It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below).  A zero-length (null) directory name in the value of PATH indicates the current directory.  A null directory
              name may appear as two adjacent colons, or as an initial or trailing colon.  The default path is system-dependent, and is set by the administrator who installs bash.  A common value is ``/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin''.

IOW you $PATH must looks like:
/usr/local/bin:/usr/bin:/bin # maybe some sbin folders too

To find valgrind with default --prefix.

Cheers,
Azat.

> > 
> > 	. . .
> > 
> > Installation directories:
> >    --prefix=PREFIX         install architecture-independent files in PREFIX
> >                            [$ac_default_prefix]
> >    --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
> >                            [PREFIX]
> > 
> > By default, \`make install' will install all the files in
> > \`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.

Re: [Valgrind-users] Is 0xC4 fixed in callgrind SVN version?

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

> vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x7D 0x2E 0x8 0x49 0x83 0xC0

-----foo.S
	.byte 0xC4,0xC2,0x7D,0x2E,0x8,0x49,0x83,0xC0
-----
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 0
    0x0:	vmaskmovps %ymm1,%ymm0,(%r8)

> ==29091== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==29091==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==29091==    you are not sure, please let us know and we'll try to fix it.


File a bug [request for enhancement] at  https://bugs.kde.org/enter_bug.cgi?product=valgrind .
Please mention the version of all software involved, which Linux distribution, etc.

In the meantime, use software which is not so highly optimized.
If that is your software, then remove "-O2", don't write assembly language, etc.
If that is an add-on shared library, then ask the supplier,
or change to an equivalent but not-so-optimized library.
If that is a built-in library such as [g]libc
then use a different Linux distribution which is not so aggressively optimized.

[Valgrind-users] Is 0xC4 fixed in callgrind SVN version?

[Mikhail K. <ka...@il...>]

Simliar to http://sourceforge.net/p/valgrind/mailman/message/31947655/


I grabbed a copy of valgrind from SVN and I'm still having trouble with
0xC4 and callgrind. Is there some branch where this is fixed? Any
suggestions?

vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x7D 0x2E 0x8 0x49
0x83 0xC0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1
vex amd64->IR:   VEX=1 VEX.L=1 VEX.nVVVV=0x0 ESC=0F38
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==29091== valgrind: Unrecognised instruction at address 0x433c64.
==29091==    at 0x433C64: ImgFetcher::getMat(std::string const&, cv::Mat&)
(fetcher.cpp:44)
==29091==    by 0x44CDE5: storeTrans(ImgFetcher&, cv::Point_<float> const&,
std::map<std::array<std::array<int, 2ul>, 2ul>, TransData,
std::less<std::array<std::array<int, 2ul>, 2ul> >,
std::allocator<std::pair<std::array<std::array<int, 2ul>, 2ul> const,
TransData> > >&, MaxDists const&) (translate.cpp:339)
==29091==    by 0x416356: main (main.cpp:337)
==29091== Your program just tried to execute an instruction that Valgrind
==29091== did not recognise.  There are two possible reasons for this.
==29091== 1. Your program has a bug and erroneously jumped to a non-code
==29091==    location.  If you are running Memcheck and you just saw a
==29091==    warning about a bad jump, it's probably your program's fault.
==29091== 2. The instruction is legitimate but Valgrind doesn't handle it,
==29091==    i.e. it's Valgrind's fault.  If you think this is the case or
==29091==    you are not sure, please let us know and we'll try to fix it.
==29091== Either way, Valgrind will now raise a SIGILL signal which will
==29091== probably kill your program.
==29091==
==29091== Process terminating with default action of signal 4 (SIGILL)
==29091==  Illegal opcode at address 0x433C64
==29091==    at 0x433C64: ImgFetcher::getMat(std::string const&, cv::Mat&)
(fetcher.cpp:44)
==29091==    by 0x44CDE5: storeTrans(ImgFetcher&, cv::Point_<float> const&,
std::map<std::array<std::array<int, 2ul>, 2ul>, TransData,
std::less<std::array<std::array<int, 2ul>, 2ul> >,
std::allocator<std::pair<std::array<std::array<int, 2ul>, 2ul> const,
TransData> > >&, MaxDists const&) (translate.cpp:339)

Re: [Valgrind-users] Help: Can't make Valgrind executable.

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

On 22.01.2015 21:21, John Reiser wrote:
>> After extracting the tar'd files, I entered the "./configure" command, then "make", then "make install".
>>
>> *Then when I try to test it with "valgrind ls -l" I get: "-bash: valgrind: command not found".**
>> *

Most likely "make install" did not succeed unless you ran it as root.
Regular users typically don't have write permissions in /usr/local which
is the default install point fro valgrind.
As John suggested use --prefix=........ when configuring. e.g.
./configure --prefix=/tmp/whatever
make && make install
/tmp/whatever/bin/valgrind ls -l

   Florian


>> There's no file in the installation folder called simply "valgrind".  (I'm expecting to find an executable file by this name.)
> 
> 
> ----- README
> To install from a tar.bz2 distribution:
> 
>    4. Run ./configure, with some options if you wish.  The only interesting
>       one is the usual --prefix=/where/you/want/it/installed.
> 
> ----- configure
> ac_default_prefix=/usr/local
> 
> 	. . .
> 
> Installation directories:
>    --prefix=PREFIX         install architecture-independent files in PREFIX
>                            [$ac_default_prefix]
>    --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
>                            [PREFIX]
> 
> By default, \`make install' will install all the files in
> \`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.
> -----
> 
> So by default you should look for  /usr/local/bin/valgrind .
> Often you would put  /usr/local/bin  as one of the paths in your
>   $PATH  shell environment variable.
> 
> 
> 
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Help: Can't make Valgrind executable.

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

> After extracting the tar'd files, I entered the "./configure" command, then "make", then "make install".
>
> *Then when I try to test it with "valgrind ls -l" I get: "-bash: valgrind: command not found".**
> *
> There's no file in the installation folder called simply "valgrind".  (I'm expecting to find an executable file by this name.)


----- README
To install from a tar.bz2 distribution:

   4. Run ./configure, with some options if you wish.  The only interesting
      one is the usual --prefix=/where/you/want/it/installed.

----- configure
ac_default_prefix=/usr/local

	. . .

Installation directories:
   --prefix=PREFIX         install architecture-independent files in PREFIX
                           [$ac_default_prefix]
   --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                           [PREFIX]

By default, \`make install' will install all the files in
\`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc.
-----

So by default you should look for  /usr/local/bin/valgrind .
Often you would put  /usr/local/bin  as one of the paths in your
  $PATH  shell environment variable.

[Valgrind-users] Help: Can't make Valgrind executable.

[Alan B. <aba...@sy...>]

Hello,

I've followed the installation directions over and over, and still can't 
get a Valgrind executable.

(My experience up to this point has been on Windows, so I may be 
overlooking something simple.)

After extracting the tar'd files, I entered the "./configure" command, 
then "make", then "make install".

*Then when I try to test it with "valgrind ls -l" I get: "-bash: 
valgrind: command not found".**
*
There's no file in the installation folder called simply "valgrind".  
(I'm expecting to find an executable file by this name.)

There are four files that start with "valgrind" and have suffixes such 
as "in", "spec", and "pc".

Linux version: Linux PS-EC3-APP1d.us.pressganey.com 
2.6.32-504.e16.x86_64 #1
SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Any ideas what I can look at/test to get an idea what's going wrong?

Thanks,
Alan

[Valgrind-users] FOSDEM valgrind devroom schedule posted (Brussels, Saturday 31 Jan 2015)

[Mark W. <mj...@re...>]

Hi Valgrind Users and Developers,

The schedule for the FOSDEM Valgrind devroom has been published:
https://fosdem.org/2015/schedule/track/valgrind/

10:30 - 11:30 Valgrind Integration in the Eclipse IDE
              Lukas Berk
11:30 - 12:30 Tuning Valgrind for your Workload
              Philippe Waroquiers
12:30 - 13:00 Extending Cachegrind: L2 Cache Inclusion & TLB Measuring
              Stavros Kaparelos
              
14:00 - 15:00 Running Valgrind on multiple processors : a prototype
              Philippe Waroquiers
15:00 - 16:00 Partial inlining of Memcheck helper function fast paths
              Julian Seward
16:00 - 17:00 How to start hacking on Valgrind by example
              Mark Wielaard
17:00 - close Valgrind Hackaton

Hope to see you all in Brussels, Saturday 31 January.

[Valgrind-users] Tool for tracing unmodified propagation of values?

[Christian C. <chr...@gm...>]

Can anyone tell me if there's a valgrind tool for doing something?

I'm trying to understand where a particular program variable's
value(s) come from.  For example, suppose some function has the
statement "int x = read_from_some_outside_source()".  And then the
value of "x" gets passed around the program in various ways: variable
assignments; parameter passing / return values; getting tucked away in
some complex data structure store on the heap, etc.  And then, in a
remote part of that program, the value is actually read into some
variable "y".

I'm looking for a tool that can tell me that "y" (at least sometimes)
ultimately gets its value from the source code location of "int x =
read_from_some_outside_source()".

This sounds a bit like the "Redux" tracer, described in a 2003 paper.
But it's not clear if that tool is still available.

It also sounds a bit like valgrind's "--trace-origins" option.  But
that option seems limited to tracking uninitialized values only,
rather than even properly initialized values like I want.

Thanks,
Christian

Re: [Valgrind-users] Empty stack shown by Valgrind

[Austin E. <aus...@gm...>]

Dear All
I am thankful to get such good guidance.

It was shared lib issue.

I had some issue in my code, that was converted to shared lib.

When I did a static linking, I was able to see the trace, and was able to
fix it.

Thank you all again.

Best regards
Austin





On Fri, Jan 2, 2015 at 8:10 PM, John Reiser <jr...@bi...> wrote:

> >> ==28501== 7 bytes in 1 blocks are indirectly lost in loss record 33 of
> 152
> >> ==28501==    at 0x402CFC7: malloc (vg_replace_malloc.c:296)
> >> ==28501==    by 0x40AF985: ???
> >> ==28501==    by 0x40AE2A1: ???
>
> As Philippe Waroquiers said in another thread,
> > So, probably you did not compile with debug info (-g option).
>
> While you wait for the re-compile and re-link using -g, it may be possible
> to get some clues by using low-level debugging techniques.  Run the
> program again, and while it is runnning then use a different terminal
> session
> to run
>         cat /proc/PID/maps
> where PID is the process ID; in the reported case PID was 28501.
> Then lookup the addresses to see which module (shared library or main
> program)
> contains each return address such as 0x40AF985, 0x40AE2A1, etc.
> Run "nm" and "readelf --symbols" on the associated modules, then
> interpolate.
>
> Those particular addresses look somewhat unusual.  If they were 16 times
> smaller
> (0x4AF985) then that might well be inside the main program.  If they were
> 16 times larger (0x400AF985) then that often is in some system-supplied
> shared library on a 32-bit i686 running Linux.  But the actual address
> 0x40AF985
> is far away from either usual case.  The original poster said
> > I checked memory leak (using Valgrind 3.10.1 in a Ubuntu 12.04 LTS
> machine)
> but omitted the hardware architecture; please state what it is.
>
> Use a debugger such as gdb to disassemble the code surrounding the return
> addresses,
> such as:        (gdb) x/20i 0x40AF985 - 0x18
> Look for references to global variables, other subroutines, constant
> values, etc.
> In some cases the numerical value of the offset to a pointer may suggest
> the use of a particular data structure.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>