Hello Fabio, or anyone else affected, Accepted valgrind into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/valgrind/1:3.13.0-1ubuntu3 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-artful to verification-done-artful. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-artful. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Description changed: + [Impact] + + Without the fix, certain valgrind tests can show non-existing failures + in the code caused by an obvious typo made in the code. + + [Test Case] + + Using the attached main.c file test case: + # gcc -Wall main.c + # valgrind -q --error-exitcode=127 --track-fds=yes --leak-check=full ./a.out + + Expect the output not to have any error related to this: + ==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== + + Also, since there is a test case added to the code, make sure the + package builds and the test passes. + + [Regression Potential] + + The issue seems to be caused by an obvious typo, but a possible + regression potential could be if the change was somehow intended and + valgrind would not preform as expected. But this would be noticed + instantly. + + [Original description] + 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 <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. ** Also affects: valgrind (Ubuntu Artful) Importance: Undecided Status: New ** Changed in: valgrind (Ubuntu) Assignee: Łukasz Zemczak (sil2100) => (unassigned) ** Changed in: valgrind (Ubuntu Artful) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-artful -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
