|
From: Jeff J. <n3...@ma...> - 2009-08-27 02:51:59
|
Hi --
I'm using helgrind from 3.5.0 on OPENMP code.
I have a lazily malloc'd pthread mutex in a static global
variable that helgrind detects.
I'd like to disable the warning somehow in code, not
with a suppression, so that I can look at more interesting
errors.
So far I've failed to be able to annotate the code to avoid the warning.
Here's the code snippet that helgrind warns me about:
static const char * cmd = NULL; /* XXX memleak */
static yarnLock oneshot = NULL; /* XXX memleak */
if (oneshot == NULL) {
cmd = rpmExpand("%{?__prelink_undo_cmd}", NULL);
VALGRIND_HG_CLEAN_MEMORY(cmd, sizeof(cmd));
oneshot = yarnNewLock(0);
VALGRIND_HG_CLEAN_MEMORY(oneshot, sizeof(oneshot));
}
yarnPossess(oneshot);
The yarnLock is basically a malloc'd posix mutex the way I'm handling.
Is there a way to annotate this code to avoid helgrind warnings?
73 de Jeff
|
|
From: Bart V. A. <bar...@gm...> - 2009-08-27 10:44:50
|
On Thu, Aug 27, 2009 at 3:51 AM, Jeff Johnson<n3...@ma...> wrote: > I'm using helgrind from 3.5.0 on OPENMP code. > > I have a lazily malloc'd pthread mutex in a static global > variable that helgrind detects. > > I'd like to disable the warning somehow in code, not > with a suppression, so that I can look at more interesting > errors. > > So far I've failed to be able to annotate the code to avoid the warning. I'm not familiar with all the details of Helgrind. But I know that DRD has a macro called DRD_IGNORE_VAR() that allows to suppress data race reports on any memory range. Bart. |
|
From: Jeff J. <n3...@ma...> - 2009-08-27 17:34:06
|
On Aug 27, 2009, at 9:33 AM, Julian Seward wrote: > >> I'm using helgrind from 3.5.0 on OPENMP code. >> >> I have a lazily malloc'd pthread mutex in a static global >> variable that helgrind detects. >> >> I'd like to disable the warning somehow in code, not >> with a suppression, so that I can look at more interesting >> errors. > > You can't use Helgrind properly on gcc/g++ compiled OpenMP code as-is, > because it doesn't understand the custom synchronisation primitives > used by libgomp.so, the support library. > Ah yes. I read that warning but did not (and do not) have sufficient experience with the OpenMP #pragma voo-doo to understand the failure symptoms. ATM I have exactly 4 #pragma statements, and I've been assuming that since helgrind so no issues with one #pragma that Fedora had compiled libgomp to use -lpthread. But the spurious false positives from helgrind are exactly in the places where I would expect complaints if futexes instead of mutexes were in use. Time to do my homework ... Helgrind looks like a very promising tool for figuring OpenMP. The #pragma instrumentation is the tip of a rather large parallelizing iceberg, and the the data scoping and scheduling primitives available in OpenMP are rather obscure and arcane even if complete. Without a tool like Helgrind, one is forced to have a very deep understanding of the inner secrets of OpenMP implementations. Thanks for the hint. 73 de Jeff |
|
From: Julian S. <js...@ac...> - 2009-08-27 18:38:49
|
> I'm using helgrind from 3.5.0 on OPENMP code. > > I have a lazily malloc'd pthread mutex in a static global > variable that helgrind detects. > > I'd like to disable the warning somehow in code, not > with a suppression, so that I can look at more interesting > errors. You can't use Helgrind properly on gcc/g++ compiled OpenMP code as-is, because it doesn't understand the custom synchronisation primitives used by libgomp.so, the support library. One solution which is known to work fairly well is to build gcc with --disable-linux-futex for the top level configure script. This causes libgomp to use pthreads primitives only, which it can see and "understand". Worth a try. J |