Comment 0 for bug 1726711

while testing some code for potential memory leaks (using valgrind) I found out that the test are failing only on Ubuntu 17.10 and the problem appears to be somewhere in the Ubuntu toolchain. I honestly can´t be 100% sure it´s a gcc / glibc or valgrind issue.

I reduce the test case to the attached main.c file.

I have tested that same piece code on the following distributions: fedora26, fedora-rawhide, rhel7.4, rhel7.5-devel, debian9, debian testing, debian unstable and debian experimental without any error.

On all the above distros:

# gcc -Wall main.c
# valgrind -q --error-exitcode=127 --track-fds=yes --leak-check=full ./a.out
<hit enter to create an epoll_event>
received event: 1
==1807== FILE DESCRIPTORS: 3 open at exit.
==1807== Open file descriptor 2: /dev/pts/0
==1807== <inherited from parent>
==1807==
==1807== Open file descriptor 1: /dev/pts/0
==1807== <inherited from parent>
==1807==
==1807== Open file descriptor 0: /dev/pts/0
==1807== <inherited from parent>
==1807==
==1807==
# echo $?
0

On ubuntu 17.10 freshly installed and fully updated:

# valgrind -q --error-exitcode=127 --track-fds=yes --leak-check=full ./a.out
==8057== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==8057== at 0x4F50C20: epoll_pwait (epoll_pwait.c:42)
==8057== by 0x108A2B: main (in /home/ubuntu/a.out)
==8057== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8057==

received event: 1
==8057== FILE DESCRIPTORS: 3 open at exit.
==8057== Open file descriptor 2: /dev/pts/4
==8057== <inherited from parent>
==8057==
==8057== Open file descriptor 1: /dev/pts/4
==8057== <inherited from parent>
==8057==
==8057== Open file descriptor 0: /dev/pts/4
==8057== <inherited from parent>
==8057==
==8057==

# echo $?
127

as you can see from the code, we don´t invoke epoll_pwait directly, we invoke only epoll_wait.

According to the man page for epoll_(p)wait, sigmask can be NULL but somehow valgrind is catching that as an error or somehow glibc epoll_wait or epoll_pwait are not treating that properly.
I don´t see any relevant code difference between glibc in debian unstable (2.24-17) or ubuntu 17.10 (2.26-0ubuntu2) that could warrant this kind of behavior.

Due to this bug, you could expect some test suite to fail. Not sure if it can have some runtime side effects tho.