So, now I'm lost because I wanted to find the code that zeroed out the memory, not the code that grew the heap. Does anyone have any hints as to where this would be located?
Edit:
As a follow up, I found the kernel's page fault handler and that's probably what calls the zeroing function. The function arch_flush_lazy_mmu_mode(); probably is the thing which does the zeroing- if you look at the macro expansion in its definition, there's assembly that uses words like 'clobber'.
Edit:
As a follow up, I found the kernel's page fault handler and that's probably what calls the zeroing function. The function arch_flush_lazy_mmu_mode(); probably is the thing which does the zeroing- if you look at the macro expansion in its definition, there's assembly that uses words like 'clobber'.
Regarding your Edit... Every page fault should not make a call to zeroing function. What if an already allocated page is paged out and a page fault for this page occurs. In this case, this page should be swapped in without zeroing. I'm guessing the zeroing occurs when heap memory gets allocated to a process during process creation, and also during any subsequent new page allocation.
ReplyDeleteThe man-page for malloc() states that it doesn't zero-out memory. If I do a malloc() and write something to memory, followed by free() and then malloc() again in the same process. The output on reading from this malloc'ed memory is not necessarily zero.
I agree, malloc will not zero out allocated memory if your program has already written to this space and then freed it. But when the OS hands you a 'fresh' page, it must be zeroed.
ReplyDelete