This is now done:
https://github.com/open-mpi/ompi/commit/a422d893b8e63347deb71bbaaa14ca25ddb1f192
On Oct 3, 2014, at 6:48 PM, Paul Hargrove wrote:
> Jeff,
>
> Using calloc() only subject to --with-valgrind sounds good to me.
> If I'd known such a option exists, I'd
Jeff,
Using calloc() only subject to --with-valgrind sounds good to me.
If I'd known such a option exists, I'd not have suggested the MCA param
idea.
-Paul
On Fri, Oct 3, 2014 at 3:33 PM, Jeff Squyres (jsquyres)
wrote:
> How about a compromise -- how about enabling
Hi Jeff,
I'd be okay with this as long as there would be a config option to revert
back to using malloc rather than calloc.
Howard
On 10/3/14 2:54 PM, Jeff Squyres (jsquyres) wrote:
WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in debug
builds?)
WHY: Drastically
How about a compromise -- how about enabling calloc() when --with-valgrind is
specified on the command line?
I.e., don't tie it to debug builds, but to valgrind-enabled builds?
On Oct 3, 2014, at 6:11 PM, Paul Hargrove wrote:
> I agree with George that zeroing memory only
I agree with George that zeroing memory only in the debug builds could hide
bugs, and thus would want to see the debug and non-debug builds have the
same behavior (both malloc or both calloc). So, I also agree this looks
initially like a hard choice.
What about using malloc() in non-debug builds
It’s a tough call. This proposal will create significant differences between
the debug and fast builds. As the entire objects will be set to zero this might
reduce bugs in the debug build, bugs that will be horribly difficult to track
in any non-debug builds. Moreover, if the structures are
WHAT: change the malloc() to calloc() in opal_obj_new() (perhaps only in debug
builds?)
WHY: Drastically reduces valgrind output
WHERE: see
https://github.com/open-mpi/ompi/blob/master/opal/class/opal_object.h#L462-L467
TIMEOUT: teleconf, Tue, Oct 14 (there's no rush)
MORE DETAIL:
I was