https://bugs.kde.org/show_bug.cgi?id=487862
--- Comment #5 from John Reiser <jrei...@bitwagon.com> --- (In reply to Mark Wielaard from comment #4) > So it seems reasonable for memcheck to assume the area exposed by brk() is > undefined. That assumption is incorrect for new pages on Linux, and there are applications that rely on the actual behavior, which is that on new pages all bytes are zero. For instance: qemu relies on this to hold data that tracks threads. > But if the pages already existed and brk() just gives them back those > aren't guaranteed to be all-zero but can contain whatever was there before. On Linux this is only partially true. If __cur_brk (the top of the sys_brk() region) varies within the same page, then the bytes retain their values. If __cur_brk decreases enough so that one or more whole pages are not contained in the allocated address space, then those pages are removed from the address space, and a subsequent sys_brk() which increases __cur_brk to include such addresses does assign new pages, and they are guaranteed to be zero. If an increasing sys_brk() would overlap with a different VMA (Linux-internal Virtual Memory Area) that already is assigned for some other purpose, then that sys_brk() fails and returns an error value. So for any successful sys_brk(), then new pages are guaranteed to be zero. Memcheck certainly knows which pages are new, and should mark then as Defined. -- You are receiving this mail because: You are watching all bug changes.
