https://bugs.kde.org/show_bug.cgi?id=381304
--- Comment #2 from John Reiser <jrei...@bitwagon.com> --- The system routines in musl libc (https://www.musl-libc.org/) are coded with the system call instruction as a common tail. The system call which produces uninit values is brk()/sbrk(), which libmusl invokes from malloc(). New pages from the OS are known to be 0, but "re-alloc()ed" pages [sbrk() of a positive increment after sbrk() of a negative increment; or a sequence of brk() whose arguments are not monotonically non-decreasing] need not be 0, and must be treated as uninit. Proving that nobody else touched the new pages (thus that they are still all initialized [namely, to zero]) can be tricky; see https://bugs.kde.org/show_bug.cgi?id=381299 . The socket() system calls is a multiplexed group of syscalls where the interpretation of arguments depends heavily on flags. Many fields are defined only in some circumstances, and there are many cases. When combined with a malloc() that does not integrate with memcheck (see https://bugs.kde.org/show_bug.cgi?id=381326) then it can look like socket() is the source of uninit. I ran into this problem while working on https://github.com/upx/upx/issues/105 . If still available, then the link https://www.dropbox.com/s/s6f6agxsjo32zzt/Uw32f.tar.gz?dl=0 (of 2017-06-16 or so) provides a pre-compiled i386 program with symbols where memcheck complains many times about socket() calls. [I have run the program many times, both bare and under memcheck; I believe it is safe to run.] It looks now like libmusl __malloc0() is the ultimate cause of all the reported problems, but it took a while to figure that out. It would have taken much less time if brk() had been identified in [all] the memcheck reports. -- You are receiving this mail because: You are watching all bug changes.
