valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Callgrind not detecting threads

[Mike L. <mik...@gm...>]

Hi John, I appreciate you taking the time to comment. I agree with your
assessments and wanted to comment on a few points.

> C'mon.  The tools re-use thread IDs because that is the easiest
> and most efficient way to track the running threads.
> If no re-use, then the next easiest way is to increment forever.
> Then the threadID cannot be an 'unsigned short', and there must be
> an adaptive hash table (or other non-trivial lookup mechanism)
> from threadID to internal thread structure, and the hash table
> must allow frequent deletions.

To clarify, I am not suggesting a change to make every thread hash to a
unique ID.
I was asking if there were any best-known-methods for detecting a new
thread in the Valgrind scheduler. For example, it looks like tools such as
Callgrind, rely on calling VG_(get_running_tid)() every basic block to
detect different threads. Using this method can produce misleading
information by conflating metadata from different threads.

Notably, Linux approaches PID generation by incrementing until the max ID
is reached, and then wrapping around and reusing any available IDs.
Although I don't know the internals of how the kernel achieves this, this
can be naively tracked with a 8KB bit vector for a 16-bit thread ID, .
I'm unaware of how Valgrind currently tracks thread IDs.

> Modify the source to suit yourself.  You will see how
> un-worthwhile the modifications are for the existing use cases.

Again, I'm not contending for Valgrind internal changes.  I would contend,
however, that being able to reliably detect when a thread starts/stops
within instrumented code is valuable.

I've seen the track_{start,stop}_client_code callbacks suggested, but I've
also seen that VG_(get_running_tid)() is supposed to be more reliable.
e.g. *http://www.mail-archive.com/val...@li.../msg03441.html
<http://www.mail-archive.com/val...@li.../msg03441.html>
*

Thank you again,
Mike

Re: [Valgrind-users] Callgrind not detecting threads

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

On 06/21/2017 Mike Lui wrote:
> It appears the thread ids are reused. That is, if thread 2 exits, and another starts, then thread 2 is reused.
> 
> Is there anyway to detect this during instrumentation, or is this a limitation of the Valgrind tools?
> When trying to separate the work of each thread, having VG_(get_running_tid)() report non-unique ID's is troublesome.

C'mon.  The tools re-use thread IDs because that is the easiest
and most efficient way to track the running threads.
If no re-use, then the next easiest way is to increment forever.
Then the threadID cannot be an 'unsigned short', and there must be
an adaptive hash table (or other non-trivial lookup mechanism)
from threadID to internal thread structure, and the hash table
must allow frequent deletions.

Modify the source to suit yourself.  You will see how
un-worthwhile the modifications are for the existing use cases.

-- 

Re: [Valgrind-users] Callgrind not detecting threads

[Mike L. <mik...@gm...>]

It appears the thread ids are reused. That is, if thread 2 exits, and
another starts, then thread 2 is reused.

Is there anyway to detect this during instrumentation, or is this a
limitation of the Valgrind tools?
When trying to separate the work of each thread, having
VG_(get_running_tid)() report non-unique ID's is troublesome.

Mike

On Wed, Jun 21, 2017 at 4:28 PM Philippe Waroquiers <
phi...@sk...> wrote:

> On Wed, 2017-06-21 at 19:17 +0000, Mike Lui wrote:
> > I posted this on the valgrind-dev mailing list a while back but didn't
> > receive a response. Hopefully some users have some input.
> >
> >
> > I'm working on a project that leverages Callgrind to generate VEX IR
> > traces. I'm using Valgrind 3.12.0.
> > I also use Callgrind's infrastructure to detect when Valgrind switches
> > thread contexts, however I'm getting unexpected behavior.
> >
> >
> > It looks like the best place to detect a thread context switch
> > in Callgrind is in CLG_(setup_bbcc) in bbcc.c  (line 561):
> >
> >
> >   /* This is needed because thread switches can not reliable be
> > tracked
> >    * with callback CLG_(run_thread) only: we have otherwise no way to
> > get
> >    * the thread ID after a signal handler returns.
> >    * This could be removed again if that bug is fixed in Valgrind.
> >    * This is in the hot path but hopefully not to costly.
> >    */
> >   tid = VG_(get_running_tid)();
> > #if 1
> >   /* CLG_(switch_thread) is a no-op when tid is equal to
> > CLG_(current_tid).
> >    * As this is on the hot path, we only call CLG_(switch_thread)(tid)
> >    * if tid differs from the CLG_(current_tid).
> >    */
> >   if (UNLIKELY(tid != CLG_(current_tid)))
> >      CLG_(switch_thread)(tid);
> >
> >
> > The above is called every instrumented basic block.
> > I've noticed strange behavior, where a thread switch would not always
> > be detected.
> > I detected the unexpected behavior with the following modifications:
> >
> >
> > To investigate further, I modified the above:
> > - if (UNLIKELY(tid != CLG_(current_tid)))
> >
> > + if (UNLIKELY(tid != CLG_(current_tid))) {
> >      CLG_(switch_thread)(tid);
> > +    VG_(printf)("Thread switched to: %d\n", tid);
> > + }
> >
> Adding --trace-sched=yes might help to understand what happens.
> Also, --trace-signals=yes might be useful if the problem is signal
> related.
>
> Philippe
>
>
>
>

Re: [Valgrind-users] Callgrind not detecting threads

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

On Wed, 2017-06-21 at 19:17 +0000, Mike Lui wrote:
> I posted this on the valgrind-dev mailing list a while back but didn't
> receive a response. Hopefully some users have some input.
> 
> 
> I'm working on a project that leverages Callgrind to generate VEX IR
> traces. I'm using Valgrind 3.12.0.
> I also use Callgrind's infrastructure to detect when Valgrind switches
> thread contexts, however I'm getting unexpected behavior.
> 
> 
> It looks like the best place to detect a thread context switch
> in Callgrind is in CLG_(setup_bbcc) in bbcc.c  (line 561):
> 
> 
>   /* This is needed because thread switches can not reliable be
> tracked
>    * with callback CLG_(run_thread) only: we have otherwise no way to
> get
>    * the thread ID after a signal handler returns.
>    * This could be removed again if that bug is fixed in Valgrind.
>    * This is in the hot path but hopefully not to costly.
>    */
>   tid = VG_(get_running_tid)();
> #if 1
>   /* CLG_(switch_thread) is a no-op when tid is equal to
> CLG_(current_tid).
>    * As this is on the hot path, we only call CLG_(switch_thread)(tid)
>    * if tid differs from the CLG_(current_tid).
>    */
>   if (UNLIKELY(tid != CLG_(current_tid)))
>      CLG_(switch_thread)(tid);
> 
> 
> The above is called every instrumented basic block.
> I've noticed strange behavior, where a thread switch would not always
> be detected.
> I detected the unexpected behavior with the following modifications:
> 
> 
> To investigate further, I modified the above:
> - if (UNLIKELY(tid != CLG_(current_tid)))
> 
> + if (UNLIKELY(tid != CLG_(current_tid))) {
>      CLG_(switch_thread)(tid);
> +    VG_(printf)("Thread switched to: %d\n", tid);
> + }
> 
Adding --trace-sched=yes might help to understand what happens.
Also, --trace-signals=yes might be useful if the problem is signal
related.

Philippe

[Valgrind-users] Callgrind not detecting threads

[Mike L. <mik...@gm...>]

I posted this on the valgrind-dev mailing list a while back but didn't
receive a response. Hopefully some users have some input.

I'm working on a project that leverages Callgrind to generate VEX IR
traces. I'm using Valgrind 3.12.0.
I also use Callgrind's infrastructure to detect when Valgrind switches
thread contexts, however I'm getting unexpected behavior.

It looks like the best place to detect a thread context switch in Callgrind is
in CLG_(setup_bbcc) in bbcc.c  (line 561):

  /* This is needed because thread switches can not reliable be tracked
   * with callback CLG_(run_thread) only: we have otherwise no way to get
   * the thread ID after a signal handler returns.
   * This could be removed again if that bug is fixed in Valgrind.
   * This is in the hot path but hopefully not to costly.
   */
  tid = VG_(get_running_tid)();
#if 1
  /* CLG_(switch_thread) is a no-op when tid is equal to CLG_(current_tid).
   * As this is on the hot path, we only call CLG_(switch_thread)(tid)
   * if tid differs from the CLG_(current_tid).
   */
  if (UNLIKELY(tid != CLG_(current_tid)))
     CLG_(switch_thread)(tid);

The above is called every instrumented basic block.
I've noticed strange behavior, where* a thread switch would not always be
detected.*
I detected the unexpected behavior with the following modifications:

To investigate further, I modified the above:
- if (UNLIKELY(tid != CLG_(current_tid)))
+ if (UNLIKELY(tid != CLG_(current_tid))) {
     CLG_(switch_thread)(tid);
+    VG_(printf)("Thread switched to: %d\n", tid);
+ }


   - With this change, I run the parsec 3.0 benchmark blackscholes with 4
   threads, input_test.tar, and expect to see *5 *threads (numbered 1-5, 1
   master and 4 worker threads) printed.
   - Under default flags, I'm seeing all 5 threads printed
   - when I add --fair-sched=yes, often I'd see the last thread (5) *not
   printed*.
   - I confirmed this behavior by printing VG_(get_running_tid)() every
   instrumented basic block.
   - I confirmed this behavior by using --separate-threads=yes for
   Callgrind. This only outputs 4 per-thread files, instead of 5.
   - I know that the thread switch happened or else the application would
   have failed.

This does not happen all the time but it happens on the majority of runs. I
also noticed that if I put a print statement in the blackscholes worker
thread, the unexpected behavior manifests far less often. I conclude it
must have something to do with the thread exiting too quickly and not
having enough work to do.

*Is this considered a bug? If not, how do I detect every time the Valgrind
thread context changes. I saw this thread
<http://valgrind-developers.narkive.com/ualztznb/thread-change-callback>from
a long time ago but I'm not sure if there's been any progress.*

$ uname -a
Linux ubuntu-VirtualBox 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24
21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

*Steps to reproduce:*
mkdir detect_thread_switch && cd detect_thread_switch
curl -L http://parsec.cs.princeton.edu/download/3.0/parsec-3.0-core.tar.gz |
tar xz
parsec-3.0/bin/parsecmgmt -a build -p blackscholes -c gcc-pthreads
tar xf parsec-3.0/pkgs/apps/blackscholes/inputs/input_test.tar

curl -L http://valgrind.org/downloads/valgrind-3.12.0.tar.bz2 | tar xj
*# MAKE THE CHANGE TO bbcc.c TO PRINT THREAD ID ON THREAD SWITCH*

cd valgrind-3.12.0 && ./autogen.sh && ./configure
make -j4 && cd ..

*# WILL SHOW THREADS 1-5*
valgrind-3.12.0/vg-in-place --tool=callgrind
parsec-3.0/pkgs/apps/blackscholes/inst/amd64-linux.gcc-pthreads/bin/blackscholes
4 in_4.txt prices.txt

*# MAY HAVE TO RUN SEVERAL TIMES IN SUCCESSION, WILL EVENTUALLY BE MISSING
THREAD 5*
valgrind-3.12.0/vg-in-place --fair-sched=yes --tool=callgrind
parsec-3.0/pkgs/apps/blackscholes/inst/amd64-linux.gcc-pthreads/bin/blackscholes
4 in_4.txt prices.txt

--------------------------------------------------------
Some example output with default flags:

==3382== Callgrind, a call-graph generating cache profiler
==3382== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et
al.
==3382== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==3382== Command:
parsec-3.0/pkgs/apps/blackscholes/inst/amd64-linux.gcc-pthreads/bin/blackscholes
4 in_4.txt prices.txt
==3382==
==3382== For interactive control, run 'callgrind_control -h'.
PARSEC Benchmark Suite Version 3.0-beta-20150206
Num of Options: 4
Num of Runs: 100
Size of data: 160
*Thread switched to: 4*
*Thread switched to: 3*
*Thread switched to: 2*
*Thread switched to: 1*
*Thread switched to: 5*
*Thread switched to: 4*
*Thread switched to: 1*
==3382==
==3382== Events    : Ir
==3382== Collected : 569502
==3382==
==3382== I   refs:      569,502

With --fair-sched=yes:
==3375== Callgrind, a call-graph generating cache profiler
==3375== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et
al.
==3375== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==3375== Command:
parsec-3.0/pkgs/apps/blackscholes/inst/amd64-linux.gcc-pthreads/bin/blackscholes
4 in_4.txt prices.txt
==3375==
==3375== For interactive control, run 'callgrind_control -h'.
PARSEC Benchmark Suite Version 3.0-beta-20150206
Num of Options: 4
Num of Runs: 100
Size of data: 160
*Thread switched to: 2*
*Thread switched to: 1*
*Thread switched to: 3*
*Thread switched to: 2*
*Thread switched to: 1*
*Thread switched to: 4*
*Thread switched to: 3*
*Thread switched to: 1*
*Thread switched to: 4*
*Thread switched to: 2*
*Thread switched to: 1*
*Thread switched to: 2*
*Thread switched to: 1*
==3375==
==3375== Events    : Ir
==3375== Collected : 569505
==3375==
==3375== I   refs:      569,505

Thanks!

[Valgrind-users] VEX inverted jumps

[Mike L. <mik...@gm...>]

I noticed there's several tools which differentiate inverted jumps from
normal jumps in the IR.

Notably Lackey, Cachegrind, and Callgrind do this instrumentation.
They all use the same heuristic:
Lackey:
// The condition of a branch was inverted by VEX if a taken
// branch is in fact a fall through according to client address

Callgrind:
/* VEX code generation sometimes inverts conditional branches.
 * As Callgrind counts (conditional) jumps, it has to correct
 * inversions. The heuristic is the following:
 * (1) Callgrind switches off SB chasing and unrolling, and
 * therefore it assumes that a candidate for inversion only is
 * the last conditional branch in an SB.
 * (2) inversion is assumed if the branch jumps to the address of
 * the next guest instruction in memory.
 * This heuristic is precalculated in CLG_(collectBlockInfo)().
 *
 * Branching behavior is also used for branch prediction. Note that
 * above heuristic is different from what Cachegrind does.
 * Cachegrind uses (2) for all branches.
 */

Could someone elaborate on this? So VEX IR produces something like the
following?:

ORIGINAL:
    cmp %rax %rcx
    jl LABEL
    <more stuff 1>
LABEL:
    <more stuff 2>

AFTER VEX:
    cmp %rax %rcx
    jge LABEL
LABEL:
    <more stuff 1>

I don't see a reason for doing this; I may be conflating concepts here.
Is this fundamentally different than my understanding of conditional
inversions in, for example, source C code?:

void foo() {
    if (condition) { }
}

goes to

void foo() {
    if (!condition) return;
    {}
}

Any insights would be helpful.

Re: [Valgrind-users] [Valgrind-developers] Migrating Valgrind sources from SVN to GIT

[Ivo R. <iv...@iv...>]

2017-06-21 4:05 GMT+02:00 Bart Van Assche <bva...@ac...>:
> On 06/16/17 08:17, Ivo Raisr wrote:
>>
>> What will be my simple workflow in new git SCM?
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Not much will be changed from the way we worked in SVN.
>> We still prepare patches, send them for review, have someone
>> with write access to push them. A minimalistic workflow would be:
>>
>> git clone git://sourceware.org/git/valgrind.git/ valgrind
>> edit/compile
>> git status/add/show
>> git pull --rebase origin/master
>> build + test
>> git commit
>> [git push - if you have write access]
>>
>> There are a lot of good tutorials on simple git workflows, so please
>> have a look. If you are using something more complicated, please
>> share with us and ideally send us a write up.
>
>
> Hello Ivo,
>
> Thank you for your detailed and very informative e-mail. As far as I know
> the current approach for sharing and reviewing patches is to create a
> bugzilla ticket, attach the patch to the bugzilla ticket and address any
> review comments that are posted in the bugzilla ticket. Servers like github
> and gitlab support a more convenient approach, namely that a developer
> clones a project into his or her personal space, publishes patches in that
> space and then sends a pull request to the maintainers. This is more
> convenient than the bugzilla attachment approach because it requires less
> work for developers and less work for reviewers. Do you perhaps know whether
> the sourceware.org server supports submitting pull requests and reviewing
> pull requests?


Hello Bart,

Thank you for raising this question.
Today this topic was discussed on IRC channel, largely between Mark and Tom.
Let me paste the whole conversation below, I find it quite interesting.
Nevertheless, to answer your question, sourceware.org does not offer
any web based interface
for submitting and reviewing pull requests. Other GNU projects, such as
gdb, binutils, elfutils, glibc, follow basically very similar approach
as Valgrind will
do after git migration.
On the other hand, if majority of Valgrind developers would like to
migrate to github
or gitlab, and Julian agrees, then I can prepare migration path to
such an environment.

Kind regards,
I.





-------------------------------------
(13:05:24) Ivosh: mjw: Bart asks if sourceware.org supports
pull-request workflow, known for example from bitbucket or github
(13:05:30) Ivosh: mjw: any idea?
(13:06:56) tomhughes: well that should be fairly easy to determine -
just look at the web site!
(13:07:07) tomhughes: but basically no
(13:07:20) tomhughes: as the 1995 vintage homepage might hint ;-)
(13:08:39) tomhughes: gitweb is all it offers in terms of a web
interface by the looks ofit
(13:20:08) sewardj: Ivosh: ach .. I had a request from Bart re github,
and forgot to forward it to you
(13:22:15) uweigand [uweigand@nat/ibm/x-uaahwvoirxjslfxe] entered the room.
(13:23:44) arnez left the room.
(13:26:47) mjw: Ivosh, It supports real git pull requests
(13:26:55) mjw: But not the web based thingy
(13:27:04) mjw: Which I never could make to work myself btw.
(13:28:03) mjw: What we do for elfutils, which is on sourceware. Is
have people have personal branches like mjw/dwarf5-line-table
(13:29:20) tomhughes: what is a "real git pull request"
(13:29:35) tomhughes: do you just mean an email asking somebody to
pull from a repo?
(13:29:42) tomhughes: I mean it's hard not to support that!
(13:30:06) mjw: then you can either just point people at that, git
send-email the changes from the master branch or do a formal git
request-pull
(13:32:14) mjw: tomhughes, yes, I do believe there are tools for
turning the web based github pull request into what basically looks
like a normal git request-pull
(13:33:22) mjw: Maybe those can be used without having github account.
But I found github too confusing. I must be missing something because
I have seen others use it just fine.
(13:34:06) mjw: It might be my reluctance to fire up a browser just to
do something simple.
(13:34:53) tomhughes: I've never really used anything other than
github - there's a few tricks to make PRs even easier to work with but
even without those it's dead simple
(13:35:02) tomhughes: Much easier than dealing with format-patch
(13:35:06) tomhughes: and emails
(13:35:26) tomhughes: I have no idea what request-pull even does
(13:35:27) mjw: really? That is all I ever use git send-email; git am
(13:35:50) tomhughes: well that's easy for you, but massively hard
work for the maintainer
(13:36:13) mjw: tomhughes, ? I am the maintainer (well for elfutils)
(13:36:33) tomhughes: I have to save the email out of thunderbird,
copy it to the right machine and then hope nothing has mangled it too
much
(13:36:40) mjw: ehe?
(13:36:58) mjw: I mainly use mutt, but I assume with thunderbird you
can also | git am
(13:37:22) tomhughes: as against "git fetch --all; git merge
openstreetmap/pull/994" for a github PR on the osm code
(13:37:37) mjw: that is really all there is to it. Look at it, do a
make check or something, reply to the email with the review or git
merge to master and push.
(13:37:38) tomhughes: I know of no way to pipe anything from thunderbirs
(13:37:56) tomhughes: and anyway if it's the office or laptop
thunderbird and the repo is on my desktop at home
(13:38:27) mjw: ah, that is a pity. Not having to leave your email
environment for simple patch apply/review is a big plus (to me)
(13:38:52) tomhughes: plus the web review interface is way nicer than
trying to read and comment on a patch in an email client
(13:39:12) tomhughes: I have no idea how the linux kernel folks get
anything done
(13:39:21) mjw: That might be a personal preference indeed
(13:39:25) tomhughes: I find it impossible to even read threads where
they are revireing patches
(13:39:44) mjw: I git completely lost in the browser, ponty-clicky
style "review" that is github.
(13:39:51) mjw: and the emails it sends are basically useless :{
(13:40:06) mjw: Interesting
(13:40:45) tomhughes: BTW the one secret hack I use is to add eg
"fetch = +refs/pull/*/head:refs/remotes/openstreetmap/pull/*" to the
github remote in .git/config so that it pulls down PRs as extra heads
for easy merging
(13:41:11) mjw: I do believe you. I am just surprised. I find the
email based workflow where you have everything together in the
relevant threads and don't need any browser/network access far
superior for my workflow.
(13:42:31) mjw: tomhughes, that might be the trick I was missing.
Looks like with that it becomes basically the user/branch workflow.
You pull all branches and then can review/apply as normal.
(13:44:14) mjw: I just don't understand how you do proper review
without using email. But that might just be because I find it natural
that (I am used to) a patch code flow equals a email conversation.
(13:44:16) tomhughes: or you can do something like
https://gist.github.com/karlhorky/0c454c0c6f894c27911ed5de58d65416 to
add a fetch-pr alias that just grabs one
(13:44:38) tomhughes: basically it's knowing they have the
refs/pull/NNN heads on the remote that you can do things with
(13:44:43) mjw: I don't really like the valgrind bugzilla workflow
either btw. But heay, that is how things are done. I'll adjust :)
(13:45:55) tomhughes: which they sort of document in
https://help.github.com/articles/checking-out-pull-requests-locally/
but only show you the slowest and most painful ways to use it ;-)
(13:46:56) mjw: I did like gerrit based workflows btw. Because you can
do anything with them just using such git tricks. And only needed the
website thingy for registering a user name.
(13:47:24) mjw: and I also heard good things about pagure and gitlab,
though I only very briefly used the former.
(13:47:41) tomhughes: I have one repo on paguro.io
(13:47:51) tomhughes: but very much looking forward to pague over distgit
(13:48:08) mjw: Those at least you can run yourself because they are
free software. The github thing is all proprietary and doesn't really
federates.
(13:48:56) tomhughes: oh sure I have quesiness about the specifics og
github as a closed source system
(13:49:15) tomhughes: but they do a good job and obviously benefit
from a network effect
(13:49:23) tomhughes: gitlad or pagure offer very similar though
(13:49:30) mjw: Then again, we (valgrind) use sourceforge for our mailinglist :)
(13:49:38) tomhughes: argh don't remind me
(13:50:03) tomhughes: and bugzilla for our issue tracker ;-)
(13:50:11) mjw: BTW. I am sure the sourceware admins would be fine
with us using it for email too. If people want.
(13:50:27) arnez [arnez@nat/ibm/x-lacatgtfuglwlnus] entered the room.
(13:50:27) tomhughes: do they have a less insane archives interface...
(13:50:52) tomhughes: simple answer: yes
(13:50:55) mjw: Only thing to be aware of is that all their lists all
open to everybody (their spam filters are really good, partly because
they just reject any HTML email).
(13:50:58) tomhughes: mainly because it would be hard not to
(13:51:21) tomhughes: err right, that's more of a user filter than a
spam filter these days?
(13:51:30) mjw: indeed :)
(13:51:34) tomhughes: or do you mean they strip the html from
multipart/alternative
(13:52:05) mjw: no, they require text/plain emails
(13:52:24) mjw: that is indeed a pretty good filter to only get developers
(13:52:40) mjw: It is less ideal for a user bases communications channel.
(13:53:43) tomhughes: it would reject the last two end-user emails to
valgrind-users for example ;-)
(13:54:08) mjw: tomhughes, BTW. When you say dist-git over pagure. Do
you mean that the fedora package repos will be moved to a pagure based
setup?
(13:54:36) tomhughes: err yes - in the next few weeks
(13:54:45) mjw: ah...
(13:54:59) ***mjw hides that he sometimes isn't paying enough
attention to fedora :)
(13:55:40) tomhughes: as part of
https://fedoraproject.org/wiki/Changes/ArbitraryBranching
(13:55:44) mjw: Which reminds me I should push and email about some
upstream rpm improvements that are coming for f27...
(13:55:52) tomhughes: well it was planned anyway but it's necessary to
do it now for that
(13:56:06) tomhughes: Julth 5th is current target
(13:57:08) mjw: fedora is sometimes hard to keep track of. Too many
places for communication and fedora-devel is a bit too high volume to
keep reading daily.
(13:58:40) mjw: This change request is a good example, I am reading
it, but still don't know what it is about :)
(13:59:49) mjw: O. I get it. We get more branches to build from.
(13:59:59) mjw: It turns dist-git into copr?
(14:00:50) mjw: I like copr. So if we just pretend that is this, then
I am all for it :)
(14:04:43) tomhughes: oh I'm unconvinced abouyt arbitrary branching
(14:05:11) tomhughes: basically you can choose your branch names and
then build the same branch into multiple koji targets if you want
(14:05:33) mjw: which is what the modularity people seem to do
(14:05:34) tomhughes: so you can have valgrind-3.11 and valgrind-3.12
as branches instead of f424, f25, f26 etc
(14:05:43) tomhughes: yeah I'm ingorning modularity
(14:06:01) mjw: which is what I am doing on copr now (kind of, except
no underlying branch, just a srpm)
(14:06:04) tomhughes: as much as possible at any rate
(14:07:53) mjw: I am happy I have a spec now that builds unchanged on
f2x, centos 6/7, dts, etc. That really makes my life a lot easier and
I can pull in feedback from various different users/use cases.
(14:08:53) mjw: I certainly see the appeal of "modularity" where you
don't care whether it is f24 or f27, but just focus on your package
and let your users pull in the one they need, instead of you
pushing/splitting things into fxx, fxy, fyy, etc.
(14:10:23) tomhughes: well as an end user I don't really want to be
having to decide what eversion of everything install on a case-by-case
basis...
(14:10:42) tomhughes: I just want to be able to update and get the
latest of everything
(14:11:10) tomhughes: nor as a maintainer do I want the extra work of
maintaining multiple version
(14:12:17) tuliom [~quassel@187.10.26.201] entered the room.
(14:28:57) mjw: tomhughes, yes, I think my viewpoint might be skewed a
bit by being responsible to keep the latest working on older RHEL.
(14:29:13) mjw: If I wasn't paid for that I might indeed not care myself...
(14:30:59) tomhughes: yeah I don't bother with RHEL for any of my packages ;-)
(14:31:52) Ivosh: hmm, interesting conversation
(14:32:32) mjw: On the other hand. I do run RHEL7 on my workstation. I
love it being super stable (read, old and boring :)
(14:33:11) mjw: It does let me focus on what I really care about
without having to worry about updates messing up integration issues.
(14:33:47) mjw: I do of course run Fedora on my laptop to keep up with
the latest and greatest. But for daily development I use RHEL.
(14:35:12) mjw: (You may of course replace RHEL with the latest Debian
stable, to get the same experience - although I do believe RHEL - or
CentOS - is actually a bit more stable and developer friendly - that
might be my employment bias though...)
(14:40:45) Ivosh: actually I run Ubuntu on my laptop and for testing
patches I download them directly from bugzilla via wget

Re: [Valgrind-users] How Can I make an andriod version with ndk.

[Julian S. <js...@ac...>]

See README.android at the root of the source tree.

J


On 20/06/17 09:16, Wuweijia wrote:
>      I  want to make android build. But I can not find the sysroot parameter in configure command. And How I can make the android version.
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] How Can I make an andriod version with ndk.

[Wuweijia <wuw...@hu...>]

     I  want to make android build. But I can not find the sysroot parameter in configure command. And How I can make the android version.

Re: [Valgrind-users] about VGDB

[Ivo R. <iv...@iv...>]

2017-06-09 21:55 GMT+02:00 Alberthus via Valgrind-users
<val...@li...>:
> Hello,
> I'm new to programing and have been learning how to debug my program with
> gdb and find leaks with valgrind, and have been trying to do them both
> together using the instructions described in section 3.2 of
> http://valgrind.org/docs/manual/manual-core-adv.html
> I have been having problems finishing the valgrind session, the suggestion
> given by the answer at
> https://stackoverflow.com/questions/37731497/quit-valgrind-cleanly-when-debugging-with-gdb,
> works but is not always, is this the way it is expected we quit valgrind?
> Later on I also found by typing on gdb:
> (gdb)monitor help
> and I found the command v.kill that also worked for me.
>
> I suggest that you change the manual so that it will also teach a way to
> quit vgdb somewhere near where you teach how to use it, will be usefull in a
> documentation

Hello Alberthus,

So if I understand it correctly, you would like to see command
"monitor v.kill" listed in a subsection
of section "3.2. Debugging your program using Valgrind gdbserver and GDB"?
For example a new subsection called "3.2.5 Disconnecting GDB from
Valgrind gdbserver"?

Let me know,
I.

[Valgrind-users] Question about the definition of DLmr, Cachegrind

[Gaoshan (Simon) <sim...@hu...>]

Dear experts

I got a couple of questions regarding the LL cache data read misses (DLmr) as below:

1.       Does it mean number of count for misses, not number of bytes?

2.       Does it mean the number of count that the data is read from external memory to last-level cache?

3.       If DLmr means number of count for misses, so does it mean the number of bytes read from external memory to last-level cache is DLmr * lineszie?

I am looking for your reply. Thanks a lot.

BR

//Simon Gao
________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

Re: [Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

[ISHIKAWA,chiaki <ish...@yk...>]

On 2017/06/16 22:55, John Reiser wrote:
> On 06/16/2017 06:31 AM, Zhiming Wang wrote:
>> By the way, just a suggestion, maybe you could publish the
>> SHA-256 checksums of release tarballs instead of MD5?
> 
> Please also publish the exact length in bytes.
> This is worth _more_ than expanding the width of the checksum,
> because it is easier (much easier) to produce checksum collisions
> by extending the length.
> 
> 

It's not signed (by PGP/GPG, for example), is it? I realized that it is 
not.(!)
(I saw no trace of signature files for verification on my local PC.)

I know all the pitfalls of signing by open keys, but it still adds a 
layer of confidence, much better than a single checksum as noted above.

Thank you again for sharing a great piece of software.

TIA

[Valgrind-users] Migrating Valgrind sources from SVN to GIT

[Ivo R. <iv...@iv...>]

Dear Valgrind community,

Now that Valgrind release 3.13.0 is out, we are pleased to announce
an imminent migration of Valgrind sources from existing Subversion SCM
to modern git SCM, as discussed during our FOSDEM 2017 Valgrind devroom
and announced publicly back at the end of February 2017.

What is going on now?
~~~~~~~~~~~~~~~~~
The migration is bound to happen in a few weeks. We are now in the last
phase of beta testing stage.
We still use the official SVN Valgrind repository for our work until
the final migration step. If you have some patches ready now, send
them for review.
You can contribute to the migration process - read below.

What will be migrated:
~~~~~~~~~~~~~~~~~
Valgrind and VEX sources. Precisely sources available today under
svn://svn.valgrind.org/valgrind and svn://svn.valgrind.org/vex, including
all production release branches and tags. Valgrind and VEX repos will
be merged into one, so no more SVN externals.

Where I will find the new repo:
~~~~~~~~~~~~~~~~~~~~~~~
At sourceware.org. Precisely at:
git://sourceware.org/git/valgrind.git/
http://sourceware.org/git/valgrind.git/
Right now a snapshot of SVN sources as of 2017-06-16 is available for
you to test.

How the test migration was performed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See recipes at https://github.com/ivosh/valgrind-git-migration

What is the plan for the migration to go forward:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Test migration has been performed and initial tests were successful.
2. The test repo is now available to test and play for others with - see below
    for details.
3. www (website) and nightly build script changes have been prepared
    in https://github.com/ivosh/valgrind-git-migration.
    They need to be reviewed.
4. Proceed once 2+3 are successfully done.
5. Announce the final migration.
6. Completely eradicate contents in the GIT repository so the migration
    can start from scratch.
7. Switch SVN valgrind+vex repo readonly.
8. Perform the final migration to sourceware.org.
9. Enable email notifications from new git repo.
10. Push www and nightly script changes to the new repo.

What will not be migrated:
~~~~~~~~~~~~~~~~~~~~
- Valgrind www (website) repo. Not now, but later.
- Non production release branches and tags from old SVN Valgrind+VEX repos.
  If you need to preserve some other branches or tags, let us know:
  https://sourceware.org/git/?p=valgrind.git;a=heads
  https://sourceware.org/git/?p=valgrind.git;a=tags

I have a write access to existing SVN repo. What shall I do for the new one?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please contact Julian Seward. He will point you to specific instructions.

What will be my simple workflow in new git SCM?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Not much will be changed from the way we worked in SVN.
We still prepare patches, send them for review, have someone
with write access to push them. A minimalistic workflow would be:

git clone git://sourceware.org/git/valgrind.git/ valgrind
edit/compile
git status/add/show
git pull --rebase origin/master
build + test
git commit
[git push - if you have write access]

There are a lot of good tutorials on simple git workflows, so please
have a look. If you are using something more complicated, please
share with us and ideally send us a write up.

I would like to help with the migration.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, please! Send us your positive and negative feedback.
For example:
- It worked for me!
- This and that did not work for me...
- How do I do such and such thing now?

The test repository is there for you to play with. The contents
will be deleted before the final migration so no reason to worry about
potential mistakes.

We also need a help documenting possible workflows. Especially when
preparing a release - we need to test and document how to work with branches
and releases.

Re: [Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

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

On 06/16/2017 06:31 AM, Zhiming Wang wrote:
> By the way, just a suggestion, maybe you could publish the
> SHA-256 checksums of release tarballs instead of MD5?

Please also publish the exact length in bytes.
This is worth _more_ than expanding the width of the checksum,
because it is easier (much easier) to produce checksum collisions
by extending the length.

Re: [Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

[Zhiming W. <zm...@gm...>]

By the way, just a suggestion, maybe you could publish the
SHA-256 checksums of release tarballs instead of MD5? MD5 was
cracked more than a decade ago (although I haven't looked into
the feasibility of producing a collision that still compiles when
unpacked).

Zhiming

Re: [Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

[Zhiming W. <zm...@gm...>]

> On Jun 16, 2017, at 9:05 AM, Mark Wielaard <ma...@kl...> wrote:
> 
> On Fri, 2017-06-16 at 08:05 -0400, Zhiming Wang wrote:
>> According to the download page
>> <http://www.valgrind.org/downloads/current.html>, the tarball of the 3.13.0 is
>> hosted at sourceware.org
>> (<ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.tar.bz2>). Is this legit?
>> Just want to make sure, because releases up until 3.12.0 were all hosted
>> directly on valgrind.org.
> 
> Yes it is. We will also soon move the code repository from subversion on
> svn.valgrind.org to git on sourceware. Website will most likely stay on
> valgrind.org and the bug tracker on bugs.kde.org.

Cool, thanks for the info.

Zhiming

Re: [Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

[Mark W. <ma...@kl...>]

On Fri, 2017-06-16 at 08:05 -0400, Zhiming Wang wrote:
> According to the download page
> <http://www.valgrind.org/downloads/current.html>, the tarball of the 3.13.0 is
> hosted at sourceware.org
> (<ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.tar.bz2>). Is this legit?
> Just want to make sure, because releases up until 3.12.0 were all hosted
> directly on valgrind.org.

Yes it is. We will also soon move the code repository from subversion on
svn.valgrind.org to git on sourceware. Website will most likely stay on
valgrind.org and the bug tracker on bugs.kde.org.

Cheers,

Mark

[Valgrind-users] Valgrind 3.13.0 tarball hosted at sourceware.org - legit or not?

[Zhiming W. <zm...@gm...>]

Hi,

According to the download page
<http://www.valgrind.org/downloads/current.html>, the tarball of the 3.13.0 is
hosted at sourceware.org
(<ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.tar.bz2>). Is this legit?
Just want to make sure, because releases up until 3.12.0 were all hosted
directly on valgrind.org.

Thanks,
Zhiming

[Valgrind-users] Valgrind-3.13.0 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.13.0,
available from http://www.valgrind.org.

3.13.0 adds support for larger processes and programs, solidifies and improves
support on existing platforms, and provides new heap-use reporting facilities.
There are, as ever, many smaller refinements and bug fixes.  The release notes
below give more details.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part of many
people.

Happy and productive debugging and profiling,

-- The Valgrind Developers



Release 3.13.0 (15 June 2017)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.13.0 is a feature release with many improvements and the usual collection of
bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.

* ==================== CORE CHANGES ===================

* The translation cache size has been increased to keep up with the demands of
  large applications.  The maximum number of sectors has increased from 24 to
  48.  The default number of sectors has increased from 16 to 32 on all
  targets except Android, where the increase is from 6 to 12.

* The amount of memory that Valgrind can use has been increased from 64GB to
  128GB.  In particular this means your application can allocate up to about
  60GB when running on Memcheck.

* Valgrind's default load address has been changed from 0x3800'0000 to
  0x5800'0000, so as to make it possible to load larger executables.  This
  should make it possible to load executables of size at least 1200MB.

* A massive spaceleak caused by reading compressed debuginfo files has been
  fixed.  Valgrind should now be entirely usable with gcc-7.0 "-gz" created
  debuginfo.

* The C++ demangler has been updated.

* Support for demangling Rust symbols has been added.

* A new representation of stack traces, the "XTree", has been added.  An XTree
  is a tree of stacktraces with data associated with the stacktraces.  This is
  used by various tools (Memcheck, Helgrind, Massif) to report on the heap
  consumption of your program.  Reporting is controlled by the new options
  --xtree-memory=none|allocs|full and --xtree-memory-file=<file>.

  A report can also be produced on demand using the gdbserver monitor command
  'xtmemory [<filename>]>'.  The XTree can be output in 2 formats: 'callgrind
  format' and 'massif format. The existing visualisers for these formats (e.g.
  callgrind_annotate, KCachegrind, ms_print) can be used to visualise and
  analyse these reports.

  Memcheck can also produce XTree leak reports using the Callgrind file
  format.  For more details, see the user manual.

* ================== PLATFORM CHANGES =================

* ppc64: support for ISA 3.0B and various fixes for existing 3.0 support

* amd64: fixes for JIT failure problems on long AVX2 code blocks

* amd64 and x86: support for CET prefixes has been added

* arm32: a few missing ARMv8 instructions have been implemented

* arm64, mips64, mips32: an alternative implementation of Load-Linked and
  Store-Conditional instructions has been added.  This is to deal with
  processor implementations that implement the LL/SC specifications strictly
  and as a result cause Valgrind to hang in certain situations.  The
  alternative implementation is automatically enabled at startup, as required.
  You can use the option --sim-hints=fallback-llsc to force-enable it if you
  want.

* Support for OSX 10.12 has been improved.

* On Linux, clone handling has been improved to honour CLONE_VFORK that
  involves a child stack.  Note however that CLONE_VFORK | CLONE_VM is handled
  like CLONE_VFORK (by removing CLONE_VM), so applications that depend on
  CLONE_VM exact semantics will (still) not work.

* The TileGX/Linux port has been removed because it appears to be both unused
  and unsupported.

* ==================== TOOL CHANGES ====================

* Memcheck:

  - Memcheck should give fewer false positives when running optimised
    Clang/LLVM generated code.

  - Support for --xtree-memory and 'xtmemory [<filename>]>'.

  - New command line options --xtree-leak=no|yes and --xtree-leak-file=<file>
    to produce the end of execution leak report in a xtree callgrind format
    file.

  - New option 'xtleak' in the memcheck leak_check monitor command, to produce
    the leak report in an xtree file.

* Massif:

  - Support for --xtree-memory and 'xtmemory [<filename>]>'.

  - For some workloads (typically, for big applications), Massif memory
    consumption and CPU consumption has decreased significantly.

* Helgrind:

  - Support for --xtree-memory and 'xtmemory [<filename>]>'.

  - addition of client request VALGRIND_HG_GNAT_DEPENDENT_MASTER_JOIN, useful
    for Ada gnat compiled applications.

* ==================== OTHER CHANGES ====================

* For Valgrind developers: in an outer/inner setup, the outer Valgrind will
  append the inner guest stacktrace to the inner host stacktrace.  This helps
  to investigate the errors reported by the outer, when they are caused by the
  inner guest program (such as an inner regtest).  See README_DEVELOPERS for
  more info.

* To allow fast detection of callgrind files by desktop environments and file
  managers, the format was extended to have an optional first line that
  uniquely identifies the format ("# callgrind format").  Callgrind creates
  this line now, as does the new xtree functionality.

* File name template arguments (such as --log-file, --xtree-memory-file, ...)
  have a new %n format letter that is replaced by a sequence number.

* "--version -v" now shows the SVN revision numbers from which Valgrind was
  built.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

162848  --log-file output isn't split when a program forks
340777  Illegal instruction on mips (ar71xx)
341481  MIPS64: Iop_CmpNE32 triggers false warning on MIPS64 platforms
342040  Valgrind mishandles clone with CLONE_VFORK | CLONE_VM that clones
        to a different stack.
344139  x86 stack-seg overrides, needed by the Wine people
344524  store conditional of guest applications always fail - observed on
        Octeon3(MIPS)
348616  Wine/valgrind: noted but unhandled ioctl 0x5390 [..] (DVD_READ_STRUCT)
352395  Please provide SVN revision info in --version -v
352767  Wine/valgrind: noted but unhandled ioctl 0x5307 [..] (CDROMSTOP)
356374  Assertion 'DRD_(g_threadinfo)[tid].pt_threadid !=
        INVALID_POSIX_THREADID' failed
358213  helgrind/drd bar_bad testcase hangs or crashes with new glibc pthread
        barrier implementation
358697  valgrind.h: Some code remains even when defining NVALGRIND
359202  Add musl libc configure/compile
360415  amd64 instructions ADCX and ADOX are not implemented in VEX
        == 372828 (vex amd64->IR: 0x66 0xF 0x3A 0x62 0x4A 0x10)
360429  unhandled ioctl 0x530d with no size/direction hints (CDROMREADMODE1)
362223  assertion failed when .valgrindrc is a directory instead of a file
367543  bt/btc/btr/bts x86/x86_64 instructions are poorly-handled wrt flags
367942  Segfault vgPlain_do_sys_sigaction (m_signals.c:1138)
368507  can't malloc chunks larger than about 34GB
368529  Android arm target link error, missing atexit and pthread_atfork
368863  WARNING: unhandled arm64-linux syscall: 100 (get_robust_list)
368865  WARNING: unhandled arm64-linux syscall: 272 (kcmp)
368868  disInstr(arm64): unhandled instruction 0xD53BE000 = cntfrq_el0 (ARMv8)
368917  WARNING: unhandled arm64-linux syscall: 218 (request_key)
368918  WARNING: unhandled arm64-linux syscall: 127 (sched_rr_get_interval)
368922  WARNING: unhandled arm64-linux syscall: 161 (sethostname)
368924  WARNING: unhandled arm64-linux syscall: 84 (sync_file_range)
368925  WARNING: unhandled arm64-linux syscall: 130 (tkill)
368926  WARNING: unhandled arm64-linux syscall: 97 (unshare)
369459  valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
370028  Reduce the number of compiler warnings on MIPS platforms
370635  arm64 missing syscall getcpu
371225  Fix order of timer_{gettime,getoverrun,settime} syscalls on arm64
371227  Clean AArch64 syscall table
371412  Rename wrap_sys_shmat to sys_shmat like other wrappers
371471  Valgrind complains about non legit memory leaks on placement new (C++)
371491  handleAddrOverrides() is [incorrect] when ASO prefix is used
371503  disInstr(arm64): unhandled instruction 0xF89F0000
371869  support '%' in symbol Z-encoding
371916  execution tree xtree concept
372120  c++ demangler demangles symbols which are not c++
372185  Support of valgrind on ARMv8 with 32 bit executable
372188  vex amd64->IR: 0x66 0xF 0x3A 0x62 0x4A 0x10 0x10 (PCMPxSTRx $0x10)
372195  Power PC, xxsel instruction is not always recognized.
372504  Hanging on exit_group
372600  process loops forever when fatal signals are arriving quickly
372794  LibVEX (arm32 front end): 'Assertion szBlg2 <= 3' failed
373046  Stacks registered by core are never deregistered
373069  memcheck/tests/leak_cpp_interior fails with GCC 5.1+
373086  Implement additional Xen hypercalls
373192  Calling posix_spawn in glibc 2.24 completely broken
373488  Support for fanotify API on ARM64 architecture
	== 368864  WARNING: unhandled arm64-linux syscall: 262 (fanotify_init)
373555  Rename BBPTR to GSPTR as it denotes guest state pointer only
373938  const IRExpr arguments for matchIRExpr()
374719  some spelling fixes
374963  increase valgrind's load address to prevent mmap failure
375514  valgrind_get_tls_addr() does not work in case of static TLS
375772  +1 error in get_elf_symbol_info() when computing value of 'hi' address
        for ML_(find_rx_mapping)()
375806  Test helgrind/tests/tc22_exit_w_lock fails with glibc 2.24
375839  Temporary storage exhausted, with long sequence of vfmadd231ps insns
        == 377159  "vex: the `impossible' happened" still present
        == 375150  Assertion 'tres.status == VexTransOK' failed
        == 378068  valgrind crashes on AVX2 function in FFmpeg
376142  Segfaults on MIPS Cavium Octeon boards
376279  disInstr(arm64): unhandled instruction 0xD50320FF
376455  Solaris: unhandled syscall lgrpsys(180)
376518  Solaris: unhandled fast trap getlgrp(6)
376611  ppc64 and arm64 don't know about prlimit64 syscall
376729  PPC64, remove R2 from the clobber list
        == 371668
376956  syswrap of SNDDRV and DRM_IOCTL_VERSION causing some addresses
        to be wrongly marked as addressable
377066  Some Valgrind unit tests fail to compile on Ubuntu 16.10 with
        PIE enabled by default
377376  memcheck/tests/linux/getregset fails with glibc2.24
377427  PPC64, lxv instruction failing on odd destination register
377478  PPC64: ISA 3.0 setup fixes
377698  Missing memory check for futex() uaddr arg for FUTEX_WAKE
        and FUTEX_WAKE_BITSET, check only 4 args for FUTEX_WAKE_BITSET,
        and 2 args for FUTEX_TRYLOCK_PI
377717  Fix massive space leak when reading compressed debuginfo sections
377891  Update Xen 4.6 domctl wrappers
377930  fcntl syscall wrapper is missing flock structure check
378524  libvexmultiarch_test regression on s390x and ppc64
378535  Valgrind reports INTERNAL ERROR in execve syscall wrapper
378673  Update libiberty demangler
378931  Add ISA 3.0B additional isnstructions, add OV32, CA32 setting support
379039  syscall wrapper prctl(PR_SET_NAME) must not check more than 16 bytes
379094  Valgrind reports INTERNAL ERROR in rt_sigsuspend syscall wrapper
379371  UNKNOWN task message [id 3444, to mach_task_self(), reply 0x603]
        (task_register_dyld_image_infos)
379372  UNKNOWN task message [id 3447, to mach_task_self(), reply 0x603]
        (task_register_dyld_shared_cache_image_info)
379390  unhandled syscall: mach:70 (host_create_mach_voucher_trap)
379473  MIPS: add support for rdhwr cycle counter register
379504  remove TileGX/Linux port
379525  Support more x86 nop opcodes
379838  disAMode(x86): not an addr!
379703  PC ISA 3.0 fixes: stxvx, stxv, xscmpexpdp instructions
379890  arm: unhandled instruction: 0xEBAD 0x1B05 (sub.w fp, sp, r5, lsl #4)
379895  clock_gettime does not execute POST syscall wrapper
379925  PPC64, mtffs does not set the FPCC and C bits in the FPSCR correctly
379966  WARNING: unhandled amd64-linux syscall: 313 (finit_module)
380200  xtree generated callgrind files refer to files without directory name
380202  Assertion failure for cache line size (cls == 64) on aarch64.
380397  s390x: __GI_strcspn() replacement needed
n-i-bz  Fix pub_tool_basics.h build issue with g++ 4.4.7.

(3.13.0.RC1:  2 June 2017, vex r3386, valgrind r16434)
(3.13.0.RC2:  9 June 2017, vex r3389, valgrind r16443)
(3.13.0:     14 June 2017, vex r3396, valgrind r16446)

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.13.0.RC1 is available for testing

[Ivo R. <iv...@iv...>]

2017-06-10 12:57 GMT+02:00 Julian Seward <js...@ac...>:
> On 02/06/17 17:57, Julian Seward wrote:
>> An RC1 tarball for 3.13.0 is now available at [..]
>
> Thank you to everybody who tried out the RC1 tarball.  There's now
> an RC2 available for testing at
>
> ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC2.tar.bz2
> (md5sum = 6f3c12c41036a59b0f49d597fbd59035)

Tested successfully on x86+amd64/Solaris 11.3 and 12.0.
I.

[Valgrind-users] 答复: 答复: hello there is a question about callgrind on the arm64.

[Wuweijia <wuw...@hu...>]

I do not know what the shadow stack meant.  Is there any idea for the option of compilation to correct it, and I can handle it quickly not modify your codes .


Owen

-----邮件原件-----
发件人: Josef Weidendorfer [mailto:Jos...@gm...] 
发送时间: 2017年6月10日 1:04
收件人: Wuweijia <wuw...@hu...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: Re: 答复: [Valgrind-users] hello there is a question about callgrind on the arm64.

Sorry, no progress on this front.

If you have any ideas to correctly synchronize real/shadow stack in callgrind and can do some tests, this would be very welcome!

Josef

Am 05.06.2017 um 10:40 schrieb Wuweijia:
> Josef:
>   Hello, is there any news now. when do you can release the patches.
> 
> Owen
> 
> 
> -----邮件原件-----
> 发件人: Josef Weidendorfer [mailto:Jos...@gm...]
> 发送时间: 2017年5月20日 6:24
> 收件人: val...@li...
> 主题: Re: [Valgrind-users] hello there is a question about callgrind on the arm64.
> 
> Hi Owen,
> 
> callgrind currently is somewhat broken on ARM, as the tracking of entering/leaving functions is unreliable.
> 
> Callgrind heavily uses the stack pointer for that.
> On x86, this works fine, as every call/return changes the SP, but on ARM, this is not the case.
> 
> There are ideas and at some point, there were patches promised by someone, but unfortunately nothing useful up to now...
> 
> Josef
> 
> 
> Am 12.05.2017 um 05:11 schrieb Wuweijia:
>> Hi :
>>
>> I ran the code through the callgrind on the x86-64, it is ok , no 
>> recursive cycle existed.
>>
>> But I ran the same the same code through the callgrind on the arm64, 
>> it show me there is recursive cycle existed.
>>
>>     Between two callgrind.out. file:
>>
>>        In arm64:
>>
>>           There is function name main’2. It meaning that there is 
>> recursive cycle. And it annote the source failed.
>>
>>        In x86_64:
>>
>>        There is no  function name  main’2  only main., It mean that 
>> there is no cycle.
>>
>>        How can I resovle it?
>>
>> The compile options : gcc g O0 ./main.cpp
>>
>> The gcc version 4.9
>>
>> Run options: valgrind --tool=callgrind ./a.out
>>
>>     Callgrind_annote option callgrind_annote auto=yes
>>
>> BR
>>
>> Owen
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Check out the vibrant tech community on one of the world's 
>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> 
> 
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.13.0.RC1 is available for testing

[Paul F. <pa...@fr...>]

On 10 Jun 2017, at 12:57, Julian Seward wrote:

> On 02/06/17 17:57, Julian Seward wrote:
>> An RC1 tarball for 3.13.0 is now available at [..]
> 
> Thank you to everybody who tried out the RC1 tarball.  There's now
> an RC2 available for testing at
> 
> ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC2.tar.bz2
> (md5sum = 6f3c12c41036a59b0f49d597fbd59035)


Hi

Here's what I see:

Vanilla Solaris 11.3 amd64:
Build OK
regtest
== 677 tests, 36 stderr failures, 8 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==

Fedora 24 amd64
Build OK
regtest
== 757 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 2 post failures ==

Mac OS 10.7.5
Build OK
Can't get regtest to build (I'm not in the habit of running tegtest on Mac).

A+
Paul

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.13.0.RC1 is available for testing

[Julian S. <js...@ac...>]

On 02/06/17 17:57, Julian Seward wrote:
> An RC1 tarball for 3.13.0 is now available at [..]

Thank you to everybody who tried out the RC1 tarball.  There's now
an RC2 available for testing at

ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC2.tar.bz2
(md5sum = 6f3c12c41036a59b0f49d597fbd59035)

Relative to the RC1, the RC2 contains the following four fixes and
is otherwise identical:

* bug 380200: xtree generated callgrind files refer to files without
  directory name

* bug 380397: Add a replacement for __GI_strcspn() required on s390x/Linux.

* bug 380202: Assertion failure for cache line size (vg_assert(cls == 64))
  on aarch64.

* n-i-bz: Fix pub_tool_basics.h build issue with g++ 4.4.7.

Unless some problem shows up with RC2, it will ship as 3.13.0 final on
Thursday 15 June.

J

[Valgrind-users] about VGDB

[Alberthus <alb...@pr...>]

Hello,
I'm new to programing and have been learning how to debug my program with gdb and find leaks with valgrind, and have been trying to do them both together using the instructions described in section 3.2 of http://valgrind.org/docs/manual/manual-core-adv.html
I have been having problems finishing the valgrind session, the suggestion given by the answer at [https://stackoverflow.com/questions/37731497/quit-valgrind-cleanly-when-debugging-with-gdb,](https://stackoverflow.com/questions/37731497/quit-valgrind-cleanly-when-debugging-with-gdb) works but is not always, is this the way it is expected we quit valgrind?
Later on I also found by typing on gdb:
(gdb)monitor help
and I found the command v.kill that also worked for me.

I suggest that you change the manual so that it will also teach a way to quit vgdb somewhere near where you teach how to use it, will be usefull in a documentation

Thanks
Alberthus.

ps. English is not my native language, sorry for grammar mistake. Feel free to point them out to me so I can improve.

Re: [Valgrind-users] cachegrind: minor documentation issue

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

Thanks, fixed as revision 16444

On Thu, 2017-06-08 at 12:11 -0500, Andy Goth wrote:
> As of today, http://valgrind.org/docs/manual/cg-manual.html includes
> the following example:
> 
> enum E { A, B, C };
> enum E e;
> enum E table[] = { 1, 2, 3 };
> int i;
> ...
> i += table[e];
> 
> I'm pretty sure the third line should be written:
> 
> int table[] = { 1, 2, 3 };
> 
> --
> Andy Goth | <andrew.m.goth/at/gmail/dot/com>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users