[Bug 1726711] Re: valgrind reports invalid memory access on epoll_pwait call when invoked via epoll_wait

[Fabio Massimo Di Nitto]

All,

tested with wget
http://launchpadlibrarian.net/342831062/valgrind_3.13.0-1ubuntu3_amd64.deb
and it´s working fine. You guys can figure out the LP paperwork magic to
get this in ;)

thanks for being so responsive on this issue.

Cheers
Fabio

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to valgrind in Ubuntu.
https://bugs.launchpad.net/bugs/1726711

Title:
  valgrind reports invalid memory access on epoll_pwait call when
  invoked via epoll_wait

Status in Valgrind:
  Unknown
Status in valgrind package in Ubuntu:
  In Progress
Status in valgrind source package in Artful:
  Fix Committed

Bug description:
  [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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/valgrind/+bug/1726711/+subscriptions