Jim Meyering <[EMAIL PROTECTED]> wrote:
...
> 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) setti
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Bruno Haible wrote:
>> Jim Meyering wrote:
>>> The RHEL bugzilla I mentioned initially is filed against glibc.
>>> Or perhaps you meant glibc's own bugzilla?
>>
>> Yes, that's what I meant: I'm not sure that Ulrich Drepper or Jakub Jelinek
>> get informed
Bruno Haible wrote:
> Jim Meyering wrote:
>> The RHEL bugzilla I mentioned initially is filed against glibc.
>> Or perhaps you meant glibc's own bugzilla?
>
> Yes, that's what I meant: I'm not sure that Ulrich Drepper or Jakub Jelinek
> get informed about Debian or RHEL bugs.
Jakub surely gets Fe
Jim Meyering wrote:
> The RHEL bugzilla I mentioned initially is filed against glibc.
> Or perhaps you meant glibc's own bugzilla?
Yes, that's what I meant: I'm not sure that Ulrich Drepper or Jakub Jelinek
get informed about Debian or RHEL bugs.
Bruno
Bruno Haible <[EMAIL PROTECTED]> 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_PERTUR
Hi Jim,
> > 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
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It would be good for gnulib to detect the bug and to use
>> the replacement snprintf on losing systems.
>
> Does the "checking whether printf survives out-of-memory conditions" test
> from gnulib (part of any of the *print-posix modul
Jim Meyering wrote:
> It would be good for gnulib to detect the bug and to use
> the replacement snprintf on losing systems.
Does the "checking whether printf survives out-of-memory conditions" test
from gnulib (part of any of the *print-posix modules) print "yes" or "no"
on the two machines you u
Using printf from GNU coreutils newer than 6.9, I get this
on rawhide (glibc-2.8.90-16) which looks wrong, but isn't serious:
(it shouldn't allocate a 30MB buffer just to fill it with '0's and
print it)
$ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0)
printf: write err
