[Bug malloc/22780] Undocumented new behavior with tcache and error/integrity checkings

["joel at porquet dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22780

--- Comment #4 from joel at porquet dot org ---
(In reply to Carlos O'Donell from comment #3)
> (In reply to joel from comment #2)
> > No, no bug to report per se. mallopt() just doesn't work like it used too,
> > and everything related to M_CHECK_ACTION seems like it was removed from the
> > texi documentation.
> > 
> > At this point, my bug report is merely frustration to have to discover the
> > new behavior (or the lack thereof) through 1/ experiencing it first hand, 2/
> > having to look at commits to understand what's going on.
> > 
> > Ideally, it would be great when such things happen that one can quickly
> > search for "mallopt M_CHECK_ACTION glibc" and find at least a short article
> > explaining that it has recently disappeared. It'd be even better if such
> > article were to explain possible workarounds.
> > 
> > Let's say that my bug report is more of a feature request: please
> > communicate more about your work and disruptive changes, instead of letting
> > people waste time figuring them out themselves.
> 
> Could you please explain in more detail exactly what is not working as you
> expect? Providing some example code, and expected versus observed behaviour
> would really help us understand your problem.

Please see http://man7.org/linux/man-pages/man3/mallopt.3.html#EXAMPLE for
details. The entire example describe a test-case with code along with the
expected behavior, which is not observed with newer versions of glibc.

> Is this bug for 2.26 for 2.27?

I'm observing this with glibc 2.26; it's the default on Archlinux.

> Regarding M_CHECK_ACTION in 2.27:
> 
> The release NEWS for 2.27 says:
> +* In order to support faster and safer process termination the malloc API
> +  family of functions will no longer print a failure address and stack
> +  backtrace after detecting heap corruption.  The goal is to minimize the
> +  amount of work done after corruption is detected and to avoid potential
> +  security issues in continued process execution.  Reducing shutdown time
> +  leads to lower overall process restart latency, so there is benefit both
> +  from a security and performance perspective.

If I read between the lines, I might understand that things won't work like
they used to, but the connection with M_CHECK_ACTION is simply missing. 

M_CHECK_ACTION is not clearly mentioned, nor the fact that it has disappear
from  mallopt's possible parameters. I don't know how I can deduce it from this
paragraph.

> The manual was adjusted to say:
> +variable @code{MALLOC_CHECK_}.  When @code{MALLOC_CHECK_} is set to a
> +non-zero value, a special (less efficient) implementation is used which
> +is designed to be tolerant against simple errors, such as double calls
> +of @code{free} with the same argument, or overruns of a single byte
> +(off-by-one bugs).  Not all such errors can be protected against,
> +however, and memory leaks can result.
> +
> +Any detected heap corruption results in immediate termination of the
> +process.

>From a user's point of view, this paragraph also doesn't tell explicitly me
that M_CHECK_ACTION has disappear, and that current code might not work like it
used to.

> We probably should have added more notes to:
> https://sourceware.org/glibc/wiki/Release/2.27#Packaging_Changes
> 
> And also we could do with documenting the new behaviour the linux man pages,
> thought that usually takes a little longer.

It seems like updating the man page should have a high priority. It's very
confusing to have mismatches between the doc and the implementation (especially
with such non-backward-compatible changes).

Thanks for your consideration.

-- 
You are receiving this mail because:
You are on the CC list for the bug.