Bug 615050 - MALLOC_PERTURB_ lacks documentation
MALLOC_PERTURB_ lacks documentation
Status: CLOSED DUPLICATE of bug 615090
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Andreas Schwab
Depends On:
  Show dependency treegraph
Reported: 2010-07-15 16:28 EDT by Jeff Bastian
Modified: 2016-11-24 11:09 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 537333
: 615090 (view as bug list)
Last Closed: 2011-06-06 05:33:03 EDT
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 (738 bytes, text/plain)
2010-07-15 17:17 EDT, Jeff Bastian
no flags Details
bits.c test program (741 bytes, text/plain)
2010-07-15 17:35 EDT, Jeff Bastian
no flags Details

  None (edit)
Description Jeff Bastian 2010-07-15 16:28:54 EDT
+++ 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):

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:
Comment 1 Jeff Bastian 2010-07-15 17:17:37 EDT
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 17:35:38 EDT
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 17:43:54 EDT
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 17:49:49 EDT
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 19:10:47 EDT
It might be a problem simply with areas of memory smaller than a machine int (4 bytes or 8 bytes)
Comment 6 Andreas Schwab 2010-07-16 03:25:25 EDT
You need space for the free block management.
Comment 7 James M. Leddy 2011-06-02 17:34:01 EDT
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 04:07:54 EDT
(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 05:33:03 EDT

*** This bug has been marked as a duplicate of bug 615090 ***
Comment 11 James M. Leddy 2011-06-06 09:44:43 EDT
(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.

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