Bug 615050
| Summary: | MALLOC_PERTURB_ lacks documentation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jeff Bastian <jbastian> | ||||||
| Component: | glibc | Assignee: | Andreas Schwab <schwab> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | qe-baseos-tools-bugs | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6.0 | CC: | 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
Jeff Bastian
2010-07-15 20:28:54 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)
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. |