** Description changed: + SRU acceptance criteria: the package builds and the test case succeeds. + This is an obvious typo. + 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 + # 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== ==1807== Open file descriptor 1: /dev/pts/0 ==1807== <inherited from parent> - ==1807== + ==1807== ==1807== Open file descriptor 0: /dev/pts/0 ==1807== <inherited from parent> - ==1807== - ==1807== + ==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 + # 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== + ==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== ==8057== Open file descriptor 1: /dev/pts/4 ==8057== <inherited from parent> - ==8057== + ==8057== ==8057== Open file descriptor 0: /dev/pts/4 ==8057== <inherited from parent> - ==8057== - ==8057== + ==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.
** Also affects: valgrind via https://bugs.kde.org/show_bug.cgi?id=381289 Importance: Unknown Status: Unknown ** Changed in: valgrind (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1726711 Title: valgrind reports invalid memory access on epoll_pwait call when invoked via epoll_wait To manage notifications about this bug go to: https://bugs.launchpad.net/valgrind/+bug/1726711/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
