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

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(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.

Is this bug for 2.26 for 2.27?

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.

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.

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.

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