Re: [Valgrind-users] Malloc/free in different threads
Thank you! Found the bug in my code!
From: Philippe Waroquiers
Sent: Friday, December 18, 2020 10:04 AM
To: Saurabh T ; Valgrind
Subject: Re: [Valgrind-users] Malloc/free in different threads
Hello,
No, valgrind/memcheck leak search is not impacted by the fact that one thread
allocates
some memory and that the release/free is done by another thread.
That should not lead to a definite leak.
So, if Valgrind tells that there are definite leaks, that is likely real leaks
to be investigated.
Philippe
On Fri, 2020-12-18 at 14:53 +, Saurabh T wrote:
> Sorry I forgot to say the false positives are for memory leaks ("definitely
> lost").
>
>
> From: Saurabh T
> Sent: Friday, December 18, 2020 9:44 AM
> To: Valgrind
> Subject: [Valgrind-users] Malloc/free in different threads
>
> Hi, I believe I am seeing lots of false positives in valgrind if I call
> free() on a different thread from the one that called malloc() -
> the pointers are exchanged between threads safely in between. Is this a known
> issue, or am I doing something wrong? Thank you.
>
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Malloc/free in different threads
Sorry I forgot to say the false positives are for memory leaks ("definitely
lost").
From: Saurabh T
Sent: Friday, December 18, 2020 9:44 AM
To: Valgrind
Subject: [Valgrind-users] Malloc/free in different threads
Hi, I believe I am seeing lots of false positives in valgrind if I call free()
on a different thread from the one that called malloc() - the pointers are
exchanged between threads safely in between. Is this a known issue, or am I
doing something wrong? Thank you.
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Malloc/free in different threads
Hi, I believe I am seeing lots of false positives in valgrind if I call free() on a different thread from the one that called malloc() - the pointers are exchanged between threads safely in between. Is this a known issue, or am I doing something wrong? Thank you. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Date: Fri, 8 Nov 2013 08:20:24 +0100 Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy From: magnus.ref...@gmail.com To: saur...@hotmail.com CC: valgrind-users@lists.sourceforge.net That is most definitely wrong. Thread 1 destroys a locked mutex, and according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html : Attempting to destroy a locked mutex results in undefined behavior. BR Magnus Reftel You are right. But I was wrong about what was going on. The mutex *is* destroyed after unlocking. Sorry. I guess I will put in a suppression for now. saurabh -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy From: philippe.waroqui...@skynet.be To: saur...@hotmail.com CC: valgrind-users@lists.sourceforge.net Date: Fri, 8 Nov 2013 22:46:28 +0100 I think this is a regression in 3.9.0 caused by revision 13642 which: Fix #323432: When calling pthread_cond_destroy or pthread_mutex_destroy with initializers as argument Helgrind (incorrectly) reports errors. The problem is that the pthread_mutex_destroy wrapper function is comparing the mutex with PTHREAD_MUTEX_INITIALIZER to detect if mutex was initialised using PTHREAD_MUTEX_INITIALIZER rather than with pthread_mutex_init. Philippe, Thank you for the patch, it worked. For what it's worth, the situation that you mention cannot happen for my code. saurabh Now, is this really a regression ? It might in fact be a feature :). If there is no synchronisation mechanism between a thread doing lock/unlock and another thread calling pthread_mutex_destroy, then if the thread doing lock/unlock is slow, the mutex could be destroyed while it is locked (or even before the locking thread has started to lock it. And then the locking thread might try to lock a destroyed mutex. Philippe -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996== at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996== by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) snip ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996== at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996== by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) snip ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996== at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) snip This was not a problem with 3.8.1 so appears to be a regression or new bug. saurabh -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: saur...@hotmail.com Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy Date: Thu, 7 Nov 2013 17:25:57 +0100 On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: snip Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh 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...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Different output from valgrind despite SSE
My x86 (ie. 32 bit) code was calculating numbers differently when run by itself (A) than when run thru valgrind (V). This is numerically intensive code so I'm certain the differences are in the floating point calculations. I understood that this could be due to the differences in floating point arithmetic (80-bit on its own vs 64-bit thru valgrind). So I rebuilt my entire code with -mfpmath=sse -msse2. This leads to different answers (B) when run on its own from before, but still they are different from valgrind (B != V). I recompiled valgrind with those options in CPPFLAGS but to no avail - this didnt change the valgrind output. Interestingly I also discovered that on x86_64, the answers from the program match exactly those from valgrind (and these are the same as from x86 valgrind = V). Basically, I cannot use valgrind to debug the 32 bit code because it doesnt take the same code path. How can I ensure that a given 32 bit x86 code makes the same floating point calculations by itself as thru valgrind? Can anyone try and answer? Even if there's no way to ensure that the answers come out the same, I'd appreciate a definite response so I dont keep on a wild goose chase. saurabh _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Different output from valgrind despite SSE
My x86 (ie. 32 bit) code was calculating numbers differently when run by itself (A) than when run thru valgrind (V). This is numerically intensive code so I'm certain the differences are in the floating point calculations. I understood that this could be due to the differences in floating point arithmetic (80-bit on its own vs 64-bit thru valgrind). So I rebuilt my entire code with -mfpmath=sse -msse2. This leads to different answers (B) when run on its own from before, but still they are different from valgrind (B != V). I recompiled valgrind with those options in CPPFLAGS but to no avail - this didnt change the valgrind output. Interestingly I also discovered that on x86_64, the answers from the program match exactly those from valgrind (and these are the same as from x86 valgrind = V). Basically, I cannot use valgrind to debug the 32 bit code because it doesnt take the same code path. How can I ensure that a given 32 bit x86 code makes the same floating point calculations by itself as thru valgrind? Thank you. saurabh _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969-- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Different output from valgrind despite SSE
My x86 (ie. 32 bit) code was calculating numbers differently when run by itself (A) than when run thru valgrind (V). This is numerically intensive code so I'm certain the differences are in the floating point calculations. I understood that this could be due to the differences in floating point arithmetic (80-bit on its own vs 64-bit thru valgrind). So I rebuilt my entire code with -mfpmath=sse -msse2. This leads to different answers (B) when run on its own from before, but still they are different from valgrind (B != V). I recompiled valgrind with those options in CPPFLAGS but to no avail - this didnt change the valgrind output. Interestingly I also discovered that on x86_64, the answers from the program match exactly those from valgrind (and these are the same as from x86 valgrind = V). Basically, I cannot use valgrind to debug the 32 bit code because it doesnt take the same code path. How can I ensure that a given 32 bit x86 code makes the same floating point calculations by itself as thru valgrind? Thank you. saurabh _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Valgrind changing inline function result
I am seeing different results from running an executable on its own vs with valgrind. The culprit is a simple C++ function that returns the square of the double passed to it (the double value is exactly the same (upto precision 20 at least); the square's 16th significant digit differs). The function happens to be inline. Is it a bug that valgrind changes the output of an executable? Is there an option etc to not make this happen? Because of the different results, I'm unable to use valgrind to track the real problem in the code. I tried adding the same numbers and function to a standalone program but that works fine. All code was built with -m32 -O2 and no other flags. gcc is 4.1, rhel 5; valgrind is 3.3.1 built on both amd64-linux and x86-linux. Thank you. saurabh _ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+worldmkt=en-USform=QBRE - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
