to indeterminism,
you have no idea what the int's value will be after 10 seconds, because it all
depends on thread scheduling by the OS.
There are many more factors for indeterminism than data races ;-)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
signature
Lev.
2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
Assuming that the program is single-threaded, this explains why the second
machine is actually slower.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
signature.asc
Description: This is
On mardi 4 avril 2023 12:11:18 CEST Nicholas Nethercote wrote:
> On Tue, 4 Apr 2023 at 19:24, David Faure wrote:
> > But then, with no cache simulation and no call stacks, what's left in
> > `cachegrind --cache-sim=no`?
>
> From the email that started this thread:
>
On lundi 3 avril 2023 23:46:46 CEST Nicholas Nethercote wrote:
> On Mon, 3 Apr 2023 at 21:36, David Faure wrote:
> > But then, what's the difference between `cachegrind --cache-sim=no`
> > and `callgrind`?
> >
> > https://accu.org/journals/overload/20/11
k whilst cachegrind gives more information about cache hit rates."
Wouldn't one want callstacks? (if this means stack traces).
I know I must be missing something, thanks for enlightening me.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
c:398)
> ==17922==by 0x57F4143: start_thread (pthread_create.c:477)
>
> To me it seems that Helgrind itself is causing the warning when calculating
> mutex_is_init (hg_intercepts.c:859).
Isn't this rather a race between unlocking a mutex
etc.) then you should give
> https://github.com/hyc/mleak/ a try. It is faster than all other memory
> leak detectors out there, fast enough to run in production. And you can
> send it a periodic signal to get a snapshot of currently allocated memory.
Or, for another LD_PRELOAD-based tool w
t; But heaptrack even reports a larger number: 153 MB!
>
> On Fri, Feb 8, 2019 at 8:09 PM David Faure wrote:
> > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > Hi,
> > > I wrote a really simple Pin tool to calculate the number of dynamically
>
ou're on Linux, I recommend using heaptrack for this :-)
https://github.com/KDAB/heaptrack
This doesn't really answer your question, sorry about that, but you might want
to see which of those tools heaptrack agrees with, it might help finding out
who is wrong...
--
David Faure, fa...@kde.
nitialized?
If I understand the architecture correctly, this should be possible to
implement, right?
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.
grind mailing-list ;-)
I admit I'm much less of a helgrind fan since tsan started to work well.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
grabbing keyboard/mouse on X11?
You can disable this by passing -nograb to the application.
> Is there any way to set valgrind to automatically generate suppression code
> instead of prompting?
Yes, --gen-suppressions=all
--
David Faure, fa...@kde.org, http://www.david
IAS_SYMBOL(ShimCppNew);
This is why it didn't happen in smaller testcases, it only happens when
including some qtwebengine headers.
=> No valgrind bug, sorry for the noise. I am now going to yell at the
qtwebengine/chromium people for polluting applications with their custom
operator n
f memory allocations hits this.
I've seen it before in other programs though so it's not specific to that test
either.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
--
BoxLayout(QWidget *parent)
: QBoxLayout(TopToBottom, parent)
{
}
QBoxLayout::QBoxLayout(Direction dir, QWidget *parent)
: QLayout(*new QBoxLayoutPrivate, 0, parent)
{
d->dir = dir;
}
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
happening?
gcc (SUSE Linux) 4.8.5
valgrind-3.13.0.SVN
glibc-2.22-3.7.x86_64
`uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016
(3ec5648) x86_64 x86_64 x86_64 GNU/Linux
OpenSuSE Leap 42.2
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Fr
On Wednesday 30 March 2016 11:28:27 Ivo Raisr wrote:
> 2016-03-30 10:59 GMT+02:00 David Faure :
>
> > This simple testcase :
> >
> > int foo() {
> > struct Foo {
> > int *i;
> > Foo() { i = new int(42); }
> >
catch the mutexes used internally
in libstdc++?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Inte
I'll ignore this for now. Thanks!
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data
g_intercepts.c:389)
==1218== Address 0x1e1f86f0 is in a rw- anonymous segment
Helgrind bug, or is clang silently ignoring thread_local?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-
On Tuesday 19 August 2014 21:57:02 Philippe Waroquiers wrote:
> On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote:
> > On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> > > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > > > ThreadSan
ndition detection but you would have to annotate either the rcu
> library or the calling code to describe the happens before
> relationships.
Are such annotations documented somewhere?
I'm still trying to find a way to annotate threadsafe-statics so that helgrind
doesn't c
w, annotating all global statics one by one sounds horrible, but actually
in my case they're already encapsulated in a macro, and I just need a way to
remove all these false positives in order for helgrind to be usable.
--
Da
void*) (testcase_local_static.cpp:16)
==31469==by 0x4C2D151: mythread_wrapper (hg_intercepts.c:233)
==31469==by 0x4E3C0DA: start_thread (pthread_create.c:309)
==31469==by 0x595B90C: clone (clone.S:111)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
#i
first place.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing
est valgrind options for
> detecting memory corruption?
The default options :-)
(memcheck tool)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
--
CenturyLi
t using valgrind:
>
> valgrind ./run.sh –e >& run log
>
> Will valgrind evaluate the shell script or my app or both?
The shell script. Better modify the shell script itself to call valgrind :)
But you can also use the above command with --trace-children=yes
and then it w
lloc.c:319)
Can you prove that the destroy cannot happen during the unlock?
> This was not a problem with 3.8.1 so appears to be a regression or new bug.
... or a fix, which detects an actual problem in the code :)
--
David Faure, fa...@k
isplay shows the before or
the after value").
This being said, helgrind might be missing suppressions for atomic_int (the
same way I'm using suppressions for Qt's QAtomicInt) - since on the special
case of x86, the two can't be distinguished by helgrind.
--
David Faure, fa..
On Friday 27 September 2013 17:51:19 Phil Longstaff wrote:
> > From: David Faure [mailto:fa...@kde.org]
> > Sent: Friday, September 27, 2013 11:18 AM
> > To: Phil Longstaff
> > Cc: valgrind-users@lists.sourceforge.net
> > Subject: Re: [Valgrind-users] FW: Helgrind to
he failed-trylock is the last thing in the chain.
If anything happens *after* a failed trylock, then one can't store a
"T1 -> anything" link.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
ation::Application() (Application.cpp:107)
==11756==by 0x415019: Application::self() (Application.cpp:208)
==11756==by 0x4152C2: main (Application.cpp:242)
==11756==
valgrind-3.9.0.SVN, freshly updated.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particula
doesn't change
that.
You see it as non-racy because "how could *my_ptr ever be something else than
10" ... but if you think about a multi-processor system, the write of the
value 10 might not get propagated to the cache of the other processor where
the read happens, since the s
On Wednesday 03 April 2013 20:59:23 Ganapathy Vijay wrote:
> I have compiled this code with the arm linux cross compiler (ofcourse with
> -g).
Did you also disable optimizations? Make sure -O2 isn't in there.
Otherwise the call to free() can get inlined, for instance.
--
Davi
unsigned int separator:0;
between the two lines, in order to make these separate memory locations.
I have no idea how compilers are supposed to implement this though.
Maybe like gcc's __sync_fetch_and_{or|and} which is an atomic operation...
Anyway -- this requires a (compliant) C++11-enabled
by 0x4C2FA44: pthread_cond_destroy@* (hg_intercepts.c:958)
==4741==by 0x400AFC: main (testcase_pthread_cond.cpp:21)
==4741==
pthread_cond_destroy 0xffefff390 in helgrind, AFTER DO_ and before CALL_
pthread_cond_destroy(0xffefff390) said 0
--
David Faure, fa...@kde.org, http://www.davidfaure.f
mfence
movl-4(%rbp), %eax
popq%rbp
.cfi_def_cfa 7, 8
@@ -403,6 +404,7 @@ _ZN10QAtomicOpsIiE12storeReleaseERii:
movq-8(%rbp), %rax
movl-12(%rbp), %edx
movl%edx, (%rax)
+ mfence
popq%rbp
.cfi_def_cfa 7, 8
re
QMutex itself having changed, doesn't
matter for helgrind's intercepts. The API is the same, so the expected
behavior is the same, so helgrind can react the same. So I think we're fine for
now.
> Once you have a patch you're satisfied with, I'd
it be OK
to ship a qt5.supp file within valgrind, and load it unconditionnally, like
xfree-4.supp is currently handled?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Framewo
implementation...
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
Index: hg_intercepts.c
===
--- hg_intercepts.c (revision 13107)
+++ hg_intercepts.c (working copy)
@@ -
On Wednesday 05 December 2012 16:52:42 Leif Walsh wrote:
> Rdunlock happens before wrlock.
... and is supposed to be about reading only, so why would CPUs bother to
propagate modified data inside that lock, to other CPUs?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on
ecommend reading "C++ Concurrency in action" by Anthony Williams, it taught
me a lot on all this all works... definitely not a simple topic.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
On Thursday 29 November 2012 23:35:03 Philippe Waroquiers wrote:
> On Thu, 2012-11-29 at 08:44 +0100, David Faure wrote:
> > > Here are the new command lines args:
> > > --show-leak-kinds=kind1,kind2,.. whi
to have "sane" defaults, so that most users don't
actually need to specify these options.
Would this mean "show for possible" and "error for definite"?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
-
On Wednesday 07 November 2012 23:00:51 Philippe Waroquiers wrote:
> On Wed, 2012-11-07 at 10:51 +0100, David Faure wrote:
> > > The idea of helgrind is that it detects lock order problems and/or
> > > race condition problems *even* if no deadlock happens and/or if no
> &
On Tuesday 06 November 2012 22:56:32 Philippe Waroquiers wrote:
> On Tue, 2012-11-06 at 13:43 +0100, David Faure wrote:
> > On Monday 05 November 2012 23:19:42 Philippe Waroquiers wrote:
> > > On Mon, 2012-11-05 at 18:59 +0100, David Faure wrote:
> > > > The testcase
On Monday 05 November 2012 23:19:42 Philippe Waroquiers wrote:
> On Mon, 2012-11-05 at 18:59 +0100, David Faure wrote:
> > The testcase http://www.davidfaure.fr/2012/qmutex_trylock.cpp
> > (from https://bugs.kde.org/show_bug.cgi?id=243232)
> > shows that an optimization
sed to annotate this tryLock() call?
PS: see my previous email about VALGRIND_HG_ENABLE_CHECKING not working. Is
this known? Should I report a bug?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular K
find out that "volatile" was used, if all that
does is disable compiler optimizations, so I agree that this cannot all work
out of the box, valgrind-specific markup is definitely needed in the Qt atomics
class. Current version of my patch attached -- no re-ENABLE for now, since
hat does the code at these two lines, say?
Unless valgrind is wrong, something funky is being done by that code, so it
might help to see what it's doing.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular
obviously.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performa
-- Forwarded Message --
Subject: Re: [Valgrind-users] helgrind and atomic operations
Date: Monday 27 August 2012, 15:25:14
From: Marc Mutz
To: David Faure
CC: valgrind-users@lists.sourceforge.net
[I can't post to valgrind-users, please fwd]
On Monday August 27 2012,
On Sunday 26 August 2012 12:53:41 Marc Mutz wrote:
> On Sunday August 26 2012, David Faure wrote:
> > On Sunday 26 August 2012 11:28:06 Julian Seward wrote:
> > > On Sunday, August 26, 2012, David Faure wrote:
> > > > Thiago expects that helgrind can&#
On Sunday 26 August 2012 11:28:06 Julian Seward wrote:
> On Sunday, August 26, 2012, David Faure wrote:
> > Thiago expects that helgrind can't autodetect this case and that helgrind-
> > macros markup is needed in Qt, I'm fine with adding that if you guys agree
> &
On Sunday 26 August 2012 01:30:43 David Faure wrote:
> On Saturday 25 August 2012 22:43:58 Julian Seward wrote:
> > Or maybe Qt really is racey
>
> Bingo :)
OK, maybe not. Turns out the code runs as intended by the Qt developers.
Marc Mutz said "
The standard say
rticular operation.
I reported this to Thiago, I'll be back with a real problem next time, not a
no-op implementation :-)
Thanks for the input.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE
ume all this is too low-level for helgrind? I.e. can it actually detect
atomic operations
and therefore validate Qt's implementation, or should we rather just "trust Qt"
and aim for
silencing helgrind whenever it sees QBasicAtomic{Integer,Pointer}?
--
David Faure, fa...@kde
57 matches
Mail list logo
