Red Hat Bugzilla – Bug 615050
MALLOC_PERTURB_ lacks documentation
Last modified: 2016-11-24 11:09:28 EST
+++ 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:
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)
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.
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.
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...
It might be a problem simply with areas of memory smaller than a machine int (4 bytes or 8 bytes) </guess>
You need space for the free block management.
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.
(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'
*** This bug has been marked as a duplicate of bug 615090 ***
(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.