On 9/17/18 11:31 PM, Philippe Waroquiers wrote:
> If you have a small reproducer, you might look at the last comment
> of the bug https://bugs.kde.org/show_bug.cgi?id=398028
> and attach the traces with the suggested debug switches.
The smallest reproducer I could come up with is a cpp file with o
On Mon, 2018-09-17 at 22:14 +0200, Alexander Brock wrote:
> On 9/17/18 7:26 PM, Julian Seward wrote:
> > > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> > > Assertion 'cfsi_fits' failed.
> >
> > Is that really still failing? I thought that got comprehensively fixed
> >
On 9/17/18 7:26 PM, Julian Seward wrote:
>> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
>> Assertion 'cfsi_fits' failed.
>
> Is that really still failing? I thought that got comprehensively fixed
> in the past few weeks. Can you re-try?
I ran "git pull" (no new commit
On 17/09/18 18:15, Alexander Brock wrote:
> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> Assertion 'cfsi_fits' failed.
Is that really still failing? I thought that got comprehensively fixed
in the past few weeks. Can you re-try?
J
_
The implementation in helgrind looks like a good way to go about this. This
is what I'm looking for.
Thanks!
Mike
On Thu, Jun 22, 2017 at 3:49 PM Philippe Waroquiers <
philippe.waroqui...@skynet.be> wrote:
> Helgrind maintains a unique thread nr by intercepting pthread_create,
> as e.g. helgrind
Helgrind maintains a unique thread nr by intercepting pthread_create,
as e.g. helgrind needs to speak about terminated threads
and so, cannot use the tid, as the tid is re-used : a new thread uses
the lowest free tid value.
See hg_main.c evh__pre_thread_ll_create, hooked up with
VG_(track_pre_thr
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 increm
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, ha
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
On Wed, 2017-06-21 at 19:17 +, 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.
>
On Dienstag, 12. Juli 2016 14:23:13 CEST Josef Weidendorfer wrote:
> Am 08.07.2016 um 01:03 schrieb Stepan Zakharov:
> > Hello,
> > If I remember correct, callgrind takes x30 overhead in general (when I
> > was running it). Usually , I had to run it on small tasks that won't
> > take more then a fe
Am 08.07.2016 um 01:03 schrieb Stepan Zakharov:
> Hello,
> If I remember correct, callgrind takes x30 overhead in general (when I
> was running it). Usually , I had to run it on small tasks that won't
> take more then a few minutes, so this was not a bother to me.
>
> But right now I am wonering if
On Fri, 2016-07-08 at 14:38 +0300, Stepan Zakharov wrote:
> Thanks. I will look into that option.
Yes, callgrind and kcachegrind are very easy to use/very precise/...,
but the price to pay is the slowness.
Other profilers having much less overhead might be good enough.
> But I can also split my ta
@lists.sourceforge.net
Subject: Re: [Valgrind-users] Callgrind longest possible run
08.07.2016, 02:04, "Stepan Zakharov" :
> Hello,
> If I remember correct, callgrind takes x30 overhead in general (when I was
> running it). Usually , I had to run it on small tasks that won't take mo
08.07.2016, 02:04, "Stepan Zakharov" :
> Hello,
> If I remember correct, callgrind takes x30 overhead in general (when I was
> running it). Usually , I had to run it on small tasks that won't take more
> then a few minutes, so this was not a bother to me.
>
> But right now I am wonering if I ca
Sorry for the slow reply... I suddenly had a dreadful thought I might have
been been checking the wrong files... (I've been using the callgrind file
format for other purposes)
But I have double checked and the problem is real.
I'm using Ubuntu Lucid and Trusty on 64bit with valgrind-3.10.0.SVN an
Am 26.09.2014 um 04:35 schrieb John Carter:
> I would assume then that
> followed_count <= total_count
> would always be true.
>
> This one liner
>
> find -name '*.callgrind' | xargs grep jcnd | ruby -nle 'p [$1, $2,$_] if
> ($_ =~ /jcnd=([0-9]+)\/([0-9]+)/) && ($1.to_i > $2.to_i)'
>
> .
gust 25, 2014 4:06 PM
To: Skarakis, Konstantinos; valgrind-users@lists.sourceforge.net
Subject: Re: [Valgrind-users] [Callgrind] jcnd in char array initialization
It appears to me that the compiler is writing to all bytes of the string in a
loop, as opposed to simply writing a 0x0 to the first
It appears to me that the compiler is writing
to all bytes of the string in a loop, as opposed
to simply writing a 0x0 to the first byte.
Regards -- Eliot Moss
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http:
You can build openmpi to have better valgrind support. See the openmpi
docs for details.
On Jul 23, 2014 4:59 AM, "Olaf Lenz" wrote:
> Hi!
>
> It looks as though I'm homing in on the culprit.
> The problem seems to be that the program is MPI-enabled. When disabling
> MPI in ESPResSo, valgrind wo
Hi!
It looks as though I'm homing in on the culprit.
The problem seems to be that the program is MPI-enabled. When disabling MPI
in ESPResSo, valgrind works fine.
It should be noted that OpenMPI provides its own compiler wrapper (mpic++)
around g++ and does some heavy meddling with the internals.
On Tue, 2014-07-22 at 15:20 +0200, Olaf Lenz wrote:
> I'm using OpenSUSE 12.3, 64bit.
> I have used current valgrind and also the SVN version, but to no
> avail.
> "nm" tells me that the debuginfo is in the binary, but valgrind won't
> find it.
>
>
> I did use valgrind to profile other binaries o
On Tue, 2014-07-22 at 14:48 +0200, Josef Weidendorfer wrote:
> Am 22.07.2014 14:31, schrieb Olaf Lenz:
> > Hi Josef!
> >
> > I have just installed valgrind-3.9.0, and it doesn't solve the problem.
> > Also, the problem seems to be there in memcheck, so it seems to be a
> > problem with the debugi
I'm using OpenSUSE 12.3, 64bit.
I have used current valgrind and also the SVN version, but to no avail.
"nm" tells me that the debuginfo is in the binary, but valgrind won't find
it.
I did use valgrind to profile other binaries on the same machine, built
with the same compiler, and it worked fine.
Am 22.07.2014 14:31, schrieb Olaf Lenz:
> Hi Josef!
>
> I have just installed valgrind-3.9.0, and it doesn't solve the problem.
> Also, the problem seems to be there in memcheck, so it seems to be a
> problem with the debuginfo loader.
> Is there a way to explicitly check the loader?
Hmm. You co
Hi Josef!
I have just installed valgrind-3.9.0, and it doesn't solve the problem.
Also, the problem seems to be there in memcheck, so it seems to be a
problem with the debuginfo loader.
Is there a way to explicitly check the loader?
Olaf
2014-07-22 10:25 GMT+02:00 Josef Weidendorfer :
> Hi Ola
Hi Olaf,
Am 21.07.2014 14:48, schrieb Olaf Lenz:
> Hi everybody!
>
> I am trying to use callgrind (3.8.0) to profile our simulation software
> ESPResSo (http://espressomd.org) on Linux.
>
> Unfortunately, callgrind seems to loose the information on where to find
> the source files when running t
Thanks Josef!
It helps me a lot!
Jintack
On May 15, 2014, at 1:47 PM, Josef Weidendorfer
wrote:
> Hi Jin,
>
> thanks, I can reproduce it.
>
> This is a bug in KCachegrind, and not in callgrind itself.
>
> For some reason, the caller/callee view does not correctly
> recognize this as recurs
Hi Jin,
thanks, I can reproduce it.
This is a bug in KCachegrind, and not in callgrind itself.
For some reason, the caller/callee view does not correctly
recognize this as recursive function call. It simply should
leave the cost column empty.
Simple workaround: just ignore.
Josef
Am 11.05.20
The version of valgrind: valgrind-3.9.0
HW/OS: Macbook pro retina(core: i7), Ubuntu 12.04 on Parallels.
Following link has the callgrind file.
https://www.dropbox.com/s/241sovlq14nrxmi/callgrind.tar.gz
I’m not sure the function name,
but the caller of the function is “create_internal_node_use_e
> While I was profiling CGAL4.4 Spatial searching with callgrind,
> I found that some function takes more than 100% of instruction. :(
> I compiled CGAL with -g and -O0 options.
>
> Is this common for other applications?
No.
> Any idea??
Tell us which version of callgrind.
Tell us the name of t
> I have a lot of calls to functions with names that I recognise,
> but which have a '2 appended to their names. These don't exist
> in the source: any idea what they signify?
They're in the callgrind documentation; they're about recursion, and
I clearly need to accumulate their call counts into t
Philippe Waroquiers wrote:
> Starting callgrind with default options, and then using
> kcachegrind on the resulting callgrind.out file, kcachegrind
> shows the nr of calls to the functions.
I'm trying to avoid using kcachegrind, because I need to automate
this process. We have tens of thousands
Am 12.02.2014 19:03, schrieb Philippe Waroquiers:
> On Wed, 2014-02-12 at 17:00 +, Dallman, John wrote:
>> That doesn't look as if there are any other events present, unless
>> they're
>> called something different. I realise I've jumped to the conclusion
>> that
>> calls are events, and this m
Am 12.02.2014 14:52, schrieb Dallman, John:
> I'm looking at using callgrind to replace an expensive Windows coverage tool,
> and for some other work where the ideas are only part-formed.
>
> The default callgrind run and callgrind_annonate display shows Ir events, but
> I only need to count funct
On Wed, 2014-02-12 at 17:00 +, Dallman, John wrote:
> That doesn't look as if there are any other events present, unless
> they're
> called something different. I realise I've jumped to the conclusion
> that
> calls are events, and this might not be true.
>
> I guess I can write something to d
Julian Seward wrote:
> I suspect not. In any case counting insns is not terribly expensive,
> so the gain you'd get would be modest.
OK.
> I suspect the names are present in the callgrind.out file, and so
> callgrind_annotate just slices out those that you list. It doesn't
> itself know the na
(guessing at both questions; JosefW would know for definite)
> The default callgrind run and callgrind_annonate display shows Ir events, but
> I only need to count function entries. Is there a way to only collect those
> and have callgrind run faster??
I suspect not. In any case counting insns
Hi,
Am 26.03.2013 13:54, schrieb Farah Saab Gmail:
> I am using callgrind tool of valgrind to profile my running code.
> Then I am using kcachegrind to view the output. The problem is that my
> native code is already slow as it is. So running it through valgrind is
> making it even more slow. Acco
Am 27.06.2012 19:38, schrieb Josef Weidendorfer:
> Am 27.06.2012 17:25, schrieb Christoph Bartoschek:
>> Hi,
>>
>> the manual does not explain all interactions between data collection and
>> instrumentation.
>>
>> I start with --instr-atstart=no
>>
>> When I then enable instrumentation with
>>
>> C
Am 27.06.2012 17:25, schrieb Christoph Bartoschek:
> Hi,
>
> the manual does not explain all interactions between data collection and
> instrumentation.
>
> I start with --instr-atstart=no
>
> When I then enable instrumentation with
>
> CALLGRIND_START_INSTRUMENTATION
>
> is collection activated?
David -
Thank for detailed explanation. Once again, I reviewed your points, my code,
valgrind/callgrind output(s).
Let me summarized briefly:
a. The CPU, the code running on is:
"
$ lscpu
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU
On 5/12/2012 8:21 AM, Michael Andronov wrote:
David -
Thank you for the speedy reply.
...like 11.5% of the time, the value is not in the cache and must be
retrieved from main memory.
That is my understanding too. I do not know how much gain I can get by
removing those 11.5%, but I would like
David -
Thank you for the speedy reply.
> ...like 11.5% of the time, the value is not in the cache and must be
> retrieved from main memory.
That is my understanding too. I do not know how much gain I can get by removing
those 11.5%, but I would like to do that.
> ...dereferencing the variabl
On 5/11/2012 8:04 PM, Michael Andronov wrote:
I'm looking for some help/hint to explain the results I'm observing with the
following peace of code:
"
…
struct CmpIndexValue {
static SListOp compare(const IndexValue& left,IndexValue&
right,ulong ity) {
__bui
On Sunday, February 26, 2012, Steve Burden wrote:
> > I don't understand why it fails unless if was added since you checked
>
> out from SVN.
>
> Ok apparently there have been some changes to the guest_amd64_toIR.c file
> since I checked out, everything runs fine with the HEAD revision :).
Are
> I don't understand why it fails unless if was added since you checked
out from SVN.
Ok apparently there have been some changes to the guest_amd64_toIR.c file
since I checked out, everything runs fine with the HEAD revision :).
Apologies for not having tested this, but what are the chances that
On Sat, 2012-02-25 at 22:10 +0100, Steve Burden wrote:
>
> I should've mentioned of course that I'm using 3.8.0-SVN, checked out
> about a week ago (at home now so I cannot check the exact revision
> number right now).
>
>
> In any case, the fresh air on the walk home made me think:
> 0x00
On 2/25/2012 4:10 PM, Steve Burden wrote:
>
> I should've mentioned of course that I'm using 3.8.0-SVN, checked out about a
> week ago (at home now
> so I cannot check the exact revision number right now).
>
> In any case, the fresh air on the walk home made me think:
> 0x0616aeee <+606>:
I should've mentioned of course that I'm using 3.8.0-SVN, checked out about
a week ago (at home now so I cannot check the exact revision number right
now).
In any case, the fresh air on the walk home made me think:
0x0616aeee <+606>: prefetchw BYTE PTR [rdi+0x340]
The prefetchw instructi
On 07.01.2012 22:59, John Reiser wrote:
>> However, after using callgrind_annotate --auto=yes, there is no information
>> for a particular function, say, "foo". The name of "foo" in the assembly is
>> "_Z10foo". I checked and evidence show that this function, which is the core
>> computational
> However, after using callgrind_annotate --auto=yes, there is no information
> for a particular function, say, "foo". The name of "foo" in the assembly is
> "_Z10foo". I checked and evidence show that this function, which is the core
> computational part, should be executed, so there should be
On Friday 19 August 2011, Asra Baig wrote:
> What is the unit of measurement of absolute cost values? Is it microsecs?
The unit depends on the event type selected to be shown by KCachegrind.
E.g. Callgrind has a cache simulator, so event types are for example
"instructions executed" or "cache miss
: Monday, June 20, 2011 2:40 PM
To: Julian Seward; valgrind-users@lists.sourceforge.net
Subject: Re: [Valgrind-users] callgrind / valgrind + intel ipp h264 decoder
gets killed in ipp libraries
Hi Julian,
Here is the dissembly for the function in question:
003393a8 :
3393a8: 55
leaveq
339456: c3 retq
339457: 90 nop
-Original Message-
From: Julian Seward [mailto:jsew...@acm.org]
Sent: Monday, June 20, 2011 1:28 PM
To: valgrind-users@lists.sourceforge.net
Cc: Abhishek Mehrotra
Subject: Re: [Valgrind
> vex amd64->IR: unhandled instruction bytes: 0x49 0xF 0xFC 0x6B 0x10 0xF
This instruction (paddb) is supported, but I think the 0x49 might be a
redundant REX prefix that causes the problem. It would help to see a
disassembly of the instruction and the few on either side; can you get
that? Runn
On Thursday 21 April 2011, Damien CLAUDE wrote:
> Hi
>
> When I launch callgrind with option --toggle-collect on a binary built
> from the source code below: valgrind --tool=callgrind
> "--toggle-collect=f1()" $BINARY
> I get the attached output file.
>
> When it is opened with kcachegrind it loo
On Thursday 21 April 2011, Frank Chang wrote:
> Good evening, I am trying to use the callgrind profiler to profile my C++
> program. I am using Valgrind version 3.6,1 on Linux Centos Version 5.5 on a
> Intel 32-bit processor. I keep getting the following error(shown
> below) when I try to profil
On Thursday 24 February 2011, Fabien wrote:
> I try to profile a parallel code on a large cluster
> (8cores per node, Intel_MPI & Open_MPI available)
> with mpirun ... valgrind --tool=callgrind --base=$PWD/callgrind.out ./exe
>
> ++ Everything seems fine when I profile from 1 to 8 cores
> (1 nod
Hi,
On Wednesday 05 May 2010, Vojtech Fried wrote:
> I wanted to measure how much time our application spends in situations like
> waiting for a locked mutex, IO, etc. - things that instruction count can
> hardly
> measure. Callgrind has an option --collect-systime that looks to be what I
> wa
Hi,
On Friday 09 October 2009, Adrian Marques wrote:
> Dear all,
>
> I'm trying to get the call graph of a program and want to limit
> callgrind's gathering of data to just my code, ignoring all functions
> within any libraries I link against.
What do you want to accomplish? Is the amount of dat
On Wednesday 01 July 2009, Evan wrote:
> It took me some time to get back to this. I ran with the --dump-instr=yes
> option, and got the following output off PMPI_Recv:
>
>
> fn=PMPI_Recv
> 0x5f870 0 48
> 0x5f875 0 48
> 0x5f87a 0 48
> 0x5f87d 0 48
> 0x5f882 0 48
> 0x5f887 0 48
> ..etc
>
> fn=PMP
It took me some time to get back to this. I ran with the --dump-instr=yes
option, and got the following output off PMPI_Recv:
fn=PMPI_Recv
0x5f870 0 48
0x5f875 0 48
0x5f87a 0 48
0x5f87d 0 48
0x5f882 0 48
0x5f887 0 48
..etc
fn=PMPI_Recv
0x1d1a6 1047 48
0x1d1a7 1047 48
0x1d1aa 1047 48
...etc
I p
On Monday 15 June 2009, Evan wrote:
> > It means that the debug reader in Valgrind was not able to detect
> > a symbol name for a given instruction address, ie. debug info seems
> > to be missing. This has nothing to do with missing command line
> > options. Build your program with debug info.
> >
On Mon, 2009-06-15 at 16:30 -0500, Evan wrote:
>
> This entry occurs:
>
> ---
> fn=PMPI_Recv
> 0 61074
> ---
>
> followed by this one:
> ---
> fn=PMPI_Recv
> 0 9477
> cob=/usr/lib/openmpi/lib/openmpi/mca_pml_ob1.so
> cfi=???
> cfn=mca_p
> It means that the debug reader in Valgrind was not able to detect
> a symbol name for a given instruction address, ie. debug info seems
> to be missing. This has nothing to do with missing command line
> options. Build your program with debug info.
>
I should have said that I am building with de
On Monday 15 June 2009, Evan wrote:
> Any suggestions as to where to look when callgrind only finds
> hexadecimal strings as function names? For instance, should I expect
> this a problem in the way I'm building the program, running it,
> passing options to callgrind...?
It means that the debug re
On Wednesday 12 November 2008, gaofeng37258 wrote:
> Hi,
>I'm a beginner of callgrind and try to use it.Now I meet a problem at
> profile my application program by callgrind.
> Callgrind exits soon after startup because of assertion fail.But i can run my
> program normally without callgrind.
68 matches
Mail list logo
