Bug 615090

Summary: MALLOC_PERTURB_ lacks documentation
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Bastian <jbastian>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED ERRATA QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: drepper, fweimer, jakub, jgarzik, mfranc, pmuller, schwab, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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 Environment:
Last Closed: 2011-05-19 13:15:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
bits.c test program none

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):
glibc-2.12-1.2.el6

How reproducible:
always

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.

http://rhn.redhat.com/errata/RHBA-2011-0584.html
Comment 6 Andreas Schwab 2011-06-06 09:33:03 UTC 
*** Bug 615050 has been marked as a duplicate of this bug. ***