Bug 615050

Summary: MALLOC_PERTURB_ lacks documentation
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Bastian <jbastian>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: fweimer, jakub, james.leddy, jgarzik, mfranc, schwab
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 537333
: 615090 (view as bug list) Environment:
Last Closed: 2011-06-06 09:33:03 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
bits.c test program none

Description Jeff Bastian 2010-07-15 20:28:54 UTC 
+++ This bug was initially created as a clone of Bug #537333 +++

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.5-49.el5_5.2

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:
Comment 1 Jeff Bastian 2010-07-15 21:17:37 UTC 
Created attachment 432231 [details]
bits.c test program

Also, from this simple test program, it appears the behavior of MALLOC_PERTURB_ has changed in RHEL 5 from that described on Ulrich's blog.

In RHEL 5, it initializes the memory to the bitwise-inverse of the MALLOC_PERTURB_ value, not the value itself.  But after freeing, the value is always 0, not the MALLOC_PERTURB_ value.  I'm not sure yet if the test program is incorrect or if glibc is clearing the memory after setting the perturb value.

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

$ MALLOC_PERTURB_=15 ./bits
Address         Action          foo             (foo2)
=======         ======          ===             ======
0x4981010       Initial value   11110000        (11110000)
0x4981010       Set to 'c'      01100011        (01100011)
0x4981010       After free      00000000        (00000000)
Comment 2 Jeff Bastian 2010-07-15 21:35:38 UTC 
Created attachment 432236 [details]
bits.c test program

Ah-hah, if I increase the amount of memory to allocate from 1-byte to 1024-bytes, it works as expected on free:

$ 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)


An updated test program is attached.
Comment 3 Jeff Bastian 2010-07-15 21:43:54 UTC 
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)

So it does initialize to the bitwise-inverse of the MALLOC_PERTURB_ value and clear it to the actual value.

This makes sense because you should recognize your MALLOC_PERTURB_ value when debugging and looking for code that re-uses freed memory.
Comment 4 James M. Leddy 2010-07-15 21:49:49 UTC 
Any idea why it only happens on 1K allocations? I was thinking maybe the compiler was implicitly allocating it on the stack because 1 byte is so puny, but it has no way of knowing that the malloc isn't being passed outside the frame, so that isn't right...
Comment 5 Jeff Garzik 2010-07-15 23:10:47 UTC 
It might be a problem simply with areas of memory smaller than a machine int (4 bytes or 8 bytes)
</guess>
Comment 6 Andreas Schwab 2010-07-16 07:25:25 UTC 
You need space for the free block management.
Comment 7 James M. Leddy 2011-06-02 21:34:01 UTC 
Since GS is the only user of this parameter, and we can't seem to get a slot to fix this in RHEL 5, I've filed this against RHEL 6.
Comment 9 Miroslav Franc 2011-06-06 08:07:54 UTC 
(In reply to comment #7)
> Since GS is the only user of this parameter, and we can't seem to get a slot to
> fix this in RHEL 5, I've filed this against RHEL 6.

Isn't this the same as bug 615090?

For 6.1 try info '(libc)Malloc Tunable Parameters'
Comment 10 Andreas Schwab 2011-06-06 09:33:03 UTC 

*** This bug has been marked as a duplicate of bug 615090 ***
Comment 11 James M. Leddy 2011-06-06 13:44:43 UTC 
(In reply to comment #10)
> 
> *** This bug has been marked as a duplicate of bug 615090 ***

Sorry, hadn't realized an engineer opened bugs against both products.