Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
>> > Is the MALLOC_PERTURB_ essential for the failure or not?
>>
>> It appears to be essential, to ensure that the internal failure
>> is manifested.
>
> Given that
>   - without MALLOC_PERTURB_, no SIGSEGV occurs,
>   - early implementations of MALLOC_PERTURB_ were buggy [1],
>
> we don't really know at this point if the bug is with snprintf() or with
> MALLOC_PERTURB_ and malloc(). Is the problem reported as a glibc bug,
> in the first place? Otherwise it won't get fixed.

Yes, of course it is reported. ;-)
The RHEL bugzilla I mentioned initially is filed against glibc.
Or perhaps you meant glibc's own bugzilla?

>> This suggests that all gnulib clients should use the replacements
>> until the upstream/vendor implementations improve.
>> Perhaps our standards are too high.
>
> I agree: I'm reading that some distributions or packages use
> MALLOC_PERTURB_ as a pre-release check. But they don't check for
> MALLOC_PERTURB_ *and* low-memory conditions simultaneously.

Not surprising.  Doing both is tricky.

> That
> is a corner case that is not relevant in practice and not relevant for
> pre-release checking. With this corner situation, you can find more
> hidden bugs in packages, but I don't think it is worth a workaround in
> gnulib.

If it turns out just to be a bug in the implementation of MALLOC_PERTURB_,
then it's not worth the effort to make gnulib work around it.

However, if it's a real error in glibc's snprintf (as I suspect) --
i.e., the MALLOC_PERTURB_=N (N!=0) setting merely ensures a consistently
reproducible failure, whereas the bug can be triggered with
MALLOC_PERTURB_=0, but under some other circumstances --
*then* it requires a work-around.