Created attachment 1166064 [details] test program illustrating valgrind bug valgrind-3.11.0 (in Fedora 23) x86-64 mishandles pselect with a null sigmask argument. It reports an error even though this is a valid use of pselect. To reproduce the problem, take the attached program pselect.c and run: gcc pselect.c valgrind ./a.out The output will say something like this: ==22567== Syscall param pselect6(sig->ss) points to unaddressable byte(s) ==22567== at 0x4F2D921: pselect (in /usr/lib64/libc-2.22.so) ==22567== by 0x400613: main (in /home/eggert/junk/a.out) ==22567== Address 0x0 is not stack'd, malloc'd or (recently) free'd This diagnostic is bogus, as the pselect call is fine.
replicated with valgrind-3.11.0-18.fc23.x86_64 and upstream valgrind This seems to be a regression since valgrind 3.10.0 doesn't show this bogus diagnostic.
Caused by this backported patch: valgrind-3.11.0-ppoll-mask.patch Which is upstream valgrind svn r15823 Sanitize signal mask in ppoll and pselect syscalls Reported and Linux patch contributed by Steven Smith <sos22.uk> Fixes BZ#359871 Which references upstream valgrind bug: https://bugs.kde.org/359871 Incorrect mask handling in ppoll
And the issue is caused by this C library/kernel ABI differences according to http://man7.org/linux/man-pages/man2/pselect6.2.html The Linux pselect6() system call modifies its timeout argument. However, the glibc wrapper function hides this behavior by using a local variable for the timeout argument that is passed to the system call. Thus, the glibc pselect() function does not modify its timeout argument; this is the behavior required by POSIX.1-2001. The final argument of the pselect6() system call is not a sigset_t * pointer, but is instead a structure of the form: struct { const sigset_t *ss; /* Pointer to signal set */ size_t ss_len; /* Size (in bytes) of object pointed to by 'ss' */ }; This allows the system call to obtain both a pointer to the signal set and its size, while allowing for the fact that most architectures support a maximum of 6 arguments to a system call. What we are seeing is glibc modifying the timeout argument (NULL) and passing it as a struct { NULL, 8 } (where 8 is the correct ss_len if ss wouldn't be NULL). valgrind doesn't check whether ss is NULL before calling PRE_MEM_READ on it and so generates the bogus warning.
Pushing bug, testcase and fix upstream: https://bugs.kde.org/show_bug.cgi?id=364413
valgrind-3.11.0-23.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d448fefa4a
valgrind-3.11.0-23.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d448fefa4a
valgrind-3.11.0-23.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.