If mallopt() is used to set M_PERTURB, then, as expected, the bytes of allocated memory are allocated to the complement of the byte in the 'value' argument. When that memory is freed, then the bytes of the region are initialized to the byte specified in 'value'. However, there is an off-by-sizeof(size_t) error in the code: instead of initializing precisely the block of memory being freed, the block starting at p+sizeof(size_t) is initialized. It looks like the two lines of this form in malloc/malloc.c free_perturb (chunk2mem(p), size - SIZE_SZ); should instead be free_perturb (p, size);
Created attachment 5071 [details] test program The following sample run of the attached program demonstrates the problem. $ ./a.out 8 0x0f # Allocate 8 bytes, M_PERTURB=0x0f f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 7b 7b 7b 7b 7b 7b 7b 7b 00 00 00 00 00 00 00 00 0f 0f 0f 0f 0f 0f 0f 0f
I checked in a patch.
The patch of 2010-10-25 changed the problem, but didn't remove it. The test program now produces the following output: $ ./a.out 8 0x0f # Allocate 8 bytes, M_PERTURB=0x0f f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 7b 7b 7b 7b 7b 7b 7b 7b 00 00 00 00 00 00 00 00 0f 0f 0f 0f 00 00 00 00 The last line of output should be: 0f 0f 0f 0f 0f 0f 0f 0f 00 00 00 00
This is tricky because it conflicts with the design of malloc. The user-visible memory area is used by fd and bk pointers to make the internal free list. I don't think there is a good way to fix this. The best I can do is add a note in the documentation about it.
(In reply to comment #4) > This is tricky because it conflicts with the design of malloc. The > user-visible memory area is used by fd and bk pointers to make the internal > free list. I don't think there is a good way to fix this. The best I can do > is add a note in the documentation about it. This isn't correct. I am not talking about the bytes that re used by the fd/bk pointers. This concerns what happens to the bytes in the usable malloc()ed area. Please look more closely at the test program.
Yes, that's the fun part. The fd and bk pointers are written within the usable area for a free block - it saves 2*sizeof(void *) per chunk. In any case, a user should not expect to be able to use them anyway for doing a check similar to what you did after free, because that is undefined - you could cause a segfault if the chunk was allocated using mmap.
(In reply to comment #6) > Yes, that's the fun part. The fd and bk pointers are written within the usable > area for a free block - it saves 2*sizeof(void *) per chunk. In any case, a > user should not expect to be able to use them anyway for doing a check similar > to what you did after free, because that is undefined - you could cause a > segfault if the chunk was allocated using mmap. Ahhh yes, I see what you mean. However, that begs the question: why do the values in the first 2* sizeof(void *) not look like pointers. (Okay, the zero could be a NULL pointer, but that seems unlikely.) I think imagine that the reason is this: this particular block of memory is in a FASTBIN, and IIRC, pointers are used there, just bitmaps of free and in use slots. Sound reasonable?
(In reply to comment #7) > However, that begs the question: why do the values in the first 2* sizeof(void > *) not look like pointers. (Okay, the zero could be a NULL pointer, but that > seems unlikely.) I think imagine that the reason is this: this particular block > of memory is in a FASTBIN, and IIRC, pointers are used there, just bitmaps of > free and in use slots. Sound reasonable? They're NULL pointers as you guessed, since the fastbins are empty in this case. In a more elaborate usage, you'll find actual pointers there, especially if a block is used long enough after it has been freed.
Resolved with an update in the documentation. It should appear on the website with the 2.17 release: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b741de23e214763ba4ffcd95829315dd315897ea