| 2017-10-24 06:36:17 |
Fabio Massimo Di Nitto |
bug |
|
|
added bug |
| 2017-10-24 06:36:17 |
Fabio Massimo Di Nitto |
attachment added |
|
reduced test case https://bugs.launchpad.net/bugs/1726711/+attachment/4990271/+files/main.c |
|
| 2017-10-24 07:09:43 |
Florian Weimer |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1462258 |
|
| 2017-10-24 07:09:43 |
Florian Weimer |
bug watch added |
|
https://bugs.kde.org/show_bug.cgi?id=381289 |
|
| 2017-10-24 07:50:56 |
Fabio Massimo Di Nitto |
affects |
glibc (Ubuntu) |
valgrind (Ubuntu) |
|
| 2017-10-24 07:50:56 |
Fabio Massimo Di Nitto |
valgrind (Ubuntu): status |
New |
Confirmed |
|
| 2017-10-24 10:00:07 |
Matthias Klose |
description |
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. |
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. |
|
| 2017-10-24 10:00:30 |
Matthias Klose |
bug task added |
|
valgrind |
|
| 2017-10-24 10:02:25 |
Matthias Klose |
valgrind (Ubuntu): status |
Confirmed |
In Progress |
|
| 2017-10-25 10:37:54 |
Łukasz Zemczak |
valgrind (Ubuntu): assignee |
|
Łukasz Zemczak (sil2100) |
|
| 2017-10-25 11:55:17 |
Łukasz Zemczak |
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. |
[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. |
|
| 2017-10-25 11:55:23 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Artful |
|
| 2017-10-25 11:55:23 |
Łukasz Zemczak |
bug task added |
|
valgrind (Ubuntu Artful) |
|
| 2017-10-25 11:55:29 |
Łukasz Zemczak |
valgrind (Ubuntu): assignee |
Łukasz Zemczak (sil2100) |
|
|
| 2017-10-25 11:59:14 |
Łukasz Zemczak |
valgrind (Ubuntu Artful): status |
New |
Fix Committed |
|
| 2017-10-25 11:59:17 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-10-25 11:59:19 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2017-10-25 11:59:22 |
Łukasz Zemczak |
tags |
|
verification-needed verification-needed-artful |
|
| 2017-10-25 12:24:34 |
Matthias Klose |
tags |
verification-needed verification-needed-artful |
verification-done verification-done-artful |
|
| 2017-10-26 08:48:21 |
Launchpad Janitor |
valgrind (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-11-01 12:11:28 |
Francis Ginther |
tags |
verification-done verification-done-artful |
id-59eef49cce27b332331e29ea verification-done verification-done-artful |
|
| 2017-11-02 16:46:44 |
Launchpad Janitor |
valgrind (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2017-11-02 16:46:47 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
