Bug 615090 - MALLOC_PERTURB_ lacks documentation
Summary: MALLOC_PERTURB_ lacks documentation
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools
: 615050 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-15 21:50 UTC by Jeff Bastian
Modified: 2018-11-14 19:29 UTC (History)
8 users (show)

Fixed In Version: glibc-2.12-1.11.el6
Doc Type: Bug Fix
Doc Text:
Details about the MALLOC_PERTURB_ (M_PERTURB) operation, which can be used to debug the use of uninitialized or freed heap memory, have been added to the documentation.
Story Points: ---
Clone Of: 615050
Last Closed: 2011-05-19 13:15:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
bits.c test program (741 bytes, text/plain)
2010-07-15 21:50 UTC, Jeff Bastian
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0584 normal SHIPPED_LIVE glibc bug fix and enhancement update 2011-05-18 17:56:51 UTC

Description Jeff Bastian 2010-07-15 21:50:21 UTC
Created attachment 432238 [details]
bits.c test program

+++ This bug was initially created as a clone of Bug #615050 +++

Description of problem:
While researching memory debugging, a mailing list post in an unrelated project pointed me to Uli's 2006 post about MALLOC_PERTURB_: http://udrepper.livejournal.com/11429.html

This LJ post is really the only description of the feature, outside of the source code itself.

Therefore, I request that mention of MALLOC_PERTURB_ be added to the glibc manual somewhere.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. man malloc
2. info malloc
Actual results:
no mention of MALLOC_PERTURB_

Expected results:
"info libc" provides some mention of MALLOC_PERTURB_

Additional info:
The behavior appears to have changed since Ulrich's blog entry: the memory is initialized to the bitwise-inverse of the perturb value and cleared to the actual value.  See the attached bits.c test program.

$ MALLOC_PERTURB_=1 ./bits
Address         Action          foo             (foo2)
=======         ======          ===             ======
0x17414010      Initial value   11111110        (11111110)
0x17414010      Set to 'c'      01100011        (01100011)
0x17414010      After free      00000001        (00000001)

$ MALLOC_PERTURB_=15 ./bits
Address         Action          foo             (foo2)
=======         ======          ===             ======
0x8d5d008       Initial value   11110000        (11110000)
0x8d5d008       Set to 'c'      01100011        (01100011)
0x8d5d008       After free      00001111        (00001111)

From the malloc.c source:
   #define alloc_perturb(p, n) memset (p, (perturb_byte ^ 0xff) & 0xff, n)
   #define free_perturb(p, n) memset (p, perturb_byte & 0xff, n)

This makes sense because you should recognize your MALLOC_PERTURB_ value when debugging and looking for code that re-uses freed memory.

Comment 4 Laura Bailey 2011-05-16 01:35:52 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:
Details about the MALLOC_PERTURB_ (M_PERTURB) operation, which can be used to debug the use of uninitialized or freed heap memory, have been added to the documentation.

Comment 5 errata-xmlrpc 2011-05-19 13:15:48 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 6 Andreas Schwab 2011-06-06 09:33:03 UTC
*** Bug 615050 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.