valgrind reports invalid memory access on epoll_pwait call when invoked via epoll_wait
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Valgrind |
Unknown
|
Unknown
|
|||
valgrind (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
Undecided
|
Unassigned |
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-
Expect the output not to have any error related to this:
==8057== Syscall param epoll_pwait(
==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-
<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-
==8057== Syscall param epoll_pwait(
==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.
description: | updated |
Changed in valgrind (Ubuntu): | |
status: | Confirmed → In Progress |
Changed in valgrind (Ubuntu): | |
assignee: | nobody → Łukasz Zemczak (sil2100) |
tags: |
added: verification-done verification-done-artful removed: verification-needed verification-needed-artful |
tags: | added: id-59eef49cce27b332331e29ea |
Changed in valgrind (Ubuntu Artful): | |
status: | Fix Committed → Fix Released |
This is a valgrind bug:
https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1462258 /bugs.kde. org/show_ bug.cgi? id=381289
https:/