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

Wed Oct 25 11:59:24 UTC 2017

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
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