[mpich-discuss] Mpich failing electric-fence check

[Lu, Huiwei]

We have found one malloc(0) line in MPID_nem_init and fixed that.
The change should be available in tomorrow’s nightly build tarball.
http://www.mpich.org/static/downloads/nightly/master/mpich/

Thanks for reporting.
—
Huiwei Lu
Postdoc Appointee
Mathematics and Computer Science Division, Argonne National Laboratory
http://www.mcs.anl.gov/~huiweilu/

On Mar 7, 2014, at 10:33 AM, Matthieu Dorier <matthieu.dorier at irisa.fr> wrote:

> I didn't know electric-fence was so old. 
> I managed to find the corruption with valgrind anyway, but it was just in case someone else wanted to use electric-fence.
> 
> Matthieu Dorier 
> PhD student at ENS Rennes 
> http://people.irisa.fr/Matthieu.Dorier 
> ----- Mail original -----
>> De: "Rob Latham" <robl at mcs.anl.gov>
>> À: discuss at mpich.org
>> Envoyé: Vendredi 7 Mars 2014 16:35:27
>> Objet: Re: [mpich-discuss] Mpich failing electric-fence check
>> 
>> 
>> 
>> On 03/07/2014 09:25 AM, Jed Brown wrote:
>>> Matthieu Dorier <matthieu.dorier at irisa.fr> writes:
>>>> ElectricFence Aborting: Allocating 0 bytes, probably a bug.
>>> 
>>> I would argue that ElectricFence is wrong here.  The standard guarantees
>>> that malloc(0) succeeds and it is useful to simplify code and to test
>>> for matching free in cases where a positive size is rare.
>> 
>> It wouldn't suprise me to find ElecritcFence buggy.  It was a great tool
>> back in the day but Perens stopped maintaining it a decade ago, and
>> there seem to be some half-hearted attempts by the community to keep it
>> active (debian has some updates from... somewhere.
>> http://duma.sourceforge.net/ might work?
>> 
>> I think everyone around here uses valgrind anyway.
>> 
>> ==rob
>> 
>> 
>> 
>>> 
>>> C99 §7.20.3: If the size of the space requested is zero, the behavior is
>>> implementation-
>>> defined: either a null pointer is returned, or the behavior is as if the
>>> size were some
>>> nonzero value, except that the returned pointer shall not be used to access
>>> an object.
>>> 
>>> Either way, the returned pointer can be passed to free.  Are you aware
>>> of current malloc implementations which violate the above?
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> discuss mailing list     discuss at mpich.org
>>> To manage subscription options or unsubscribe:
>>> https://lists.mpich.org/mailman/listinfo/discuss
>>> 
>> 
>> --
>> Rob Latham
>> Mathematics and Computer Science Division
>> Argonne National Lab, IL USA
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>> 
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss