Bug 615050 - MALLOC_PERTURB_ lacks documentation
Summary: MALLOC_PERTURB_ lacks documentation
Status: CLOSED DUPLICATE of bug 615090
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-15 20:28 UTC by Jeff Bastian
Modified: 2016-11-24 16:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 537333
: 615090 (view as bug list)
Last Closed: 2011-06-06 09:33:03 UTC
Target Upstream Version:

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

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

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

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.

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