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 debugging some code today and came across a bunch of places where we write structs down various IPC mechanisms, and the structs contain holes. In most places, the performance doesn't matter / the readability of struct members is more important, so we haven't re-ordered the structs to remove holes. But consequently, those holes end up uninitialized, and therefore memcpy()ing or write()ing instances of these structs causes valgrind to emit warnings. The patch below eliminates most (all?) of these valgrind warnings -- in debug builds, it changes the malloc() inside OBJ_NEW to a calloc(). Upon a little more thought, however, I wonder if we use OBJ_NEW in any fast code paths (other than in bulk, such as when we need to grow a free list). Specifically: would it be terrible to *always* calloc -- not just for debug builds? ----- diff --git a/opal/class/opal_object.h b/opal/class/opal_object.h index 7012bac..585f13e 100644 --- a/opal/class/opal_object.h +++ b/opal/class/opal_object.h @@ -464,7 +464,11 @@ static inline opal_object_t *opal_obj_new(opal_class_t * cl opal_object_t *object; assert(cls->cls_sizeof >= sizeof(opal_object_t)); +#if OPAL_ENABLE_DEBUG + object = (opal_object_t *) calloc(1, cls->cls_sizeof); +#else object = (opal_object_t *) malloc(cls->cls_sizeof); +#endif if (0 == cls->cls_initialized) { opal_class_initialize(cls); } ----- -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
