615050 – MALLOC_PERTURB_ lacks documentation

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 615050 - MALLOC_PERTURB_ lacks documentation

Summary: MALLOC_PERTURB_ lacks documentation

Keywords:
Status:	CLOSED DUPLICATE of bug 615090
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	glibc
Sub Component:
Version:	6.0
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Andreas Schwab
QA Contact:	qe-baseos-tools-bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2010-07-15 20:28 UTC by Jeff Bastian
Modified:	2016-11-24 16:09 UTC (History)
CC List:	6 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:	537333
Clones:	615090 (view as bug list)
Environment:
Last Closed:	2011-06-06 09:33:03 UTC
Target Upstream Version:
Embargoed:

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
Show Obsolete (1) View All

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.

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