Activity log for bug #1770676

Date Who What changed Old value New value Message
2018-05-11 15:46:58 Scott Emmons bug added bug
2018-05-11 15:46:58 Scott Emmons attachment added Testcase https://bugs.launchpad.net/bugs/1770676/+attachment/5137804/+files/testcase.c
2018-05-11 15:47:15 Scott Emmons bug added subscriber Netflix Engineering
2018-05-11 15:54:44 Scott Emmons bug task added gcc-5 (Ubuntu)
2018-05-11 15:55:01 Scott Emmons description Note: Package gcc-7 selected, but this affects other gcc versions. While investigating why cronolog was no longer changing a log symlink in bionic, I discovered a bug in gcc (reproducable in 7.3.0-16ubuntu3 in bionic and 5.4.0-6ubuntu1~16.04.9 in xenial) for code compiled with -O2. I have created a simple testcase to reproduce the problem, which is attached. You can reproduce the problem with the following: # ==== set -x echo "First, we compile and run without optimization:" gcc -o testcase testcase.c && ./testcase echo "Then, we compile and run with optimization:" gcc -O2 -o testcase testcase.c && ./testcase # ==== Which outputs: + echo 'First, we compile and run without optimization:' First, we compile and run without optimization: + gcc -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is NULL (expected) foo in main() is NULL (expected) foo in main() is NULL (expected) + echo 'Then, we compile and run with optimization:' Then, we compile and run with optimization: + gcc -O2 -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is not NULL (NOT EXPECTED!) foo in main() is NULL (expected) foo in main() is NULL (expected) The problem occurs after calling: stat(foo, &stat_buf); Where foo is a NULL pointer. After the return from this function, foo will no longer be NULL when the code is compiled with optimization. (You can argue calling stat with a NULL pointer is bad behavior, however this code has been in cronolog, working fine when compiled with -O2, for years). I can reproduce this easily on multiple systems, bionic with "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0" and xenial with "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609". I could not initially reproduce the cronolog testcase in xenial, leading me to some suspicion that it may be related to retpoline or other recent compiler changes - and in fact after recompiling cronolog on xenial I can reproduce the issue there as well. While investigating why cronolog was no longer changing a log symlink in bionic, I discovered a bug in gcc (reproducable in 7.3.0-16ubuntu3 in bionic and 5.4.0-6ubuntu1~16.04.9 in xenial) for code compiled with -O2. I have created a simple testcase to reproduce the problem, which is attached. You can reproduce the problem with the following: # ==== set -x echo "First, we compile and run without optimization:" gcc -o testcase testcase.c && ./testcase echo "Then, we compile and run with optimization:" gcc -O2 -o testcase testcase.c && ./testcase # ==== Which outputs: + echo 'First, we compile and run without optimization:' First, we compile and run without optimization: + gcc -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is NULL (expected) foo in main() is NULL (expected) foo in main() is NULL (expected) + echo 'Then, we compile and run with optimization:' Then, we compile and run with optimization: + gcc -O2 -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is not NULL (NOT EXPECTED!) foo in main() is NULL (expected) foo in main() is NULL (expected) The problem occurs after calling:   stat(foo, &stat_buf); Where foo is a NULL pointer. After the return from this function, foo will no longer be NULL when the code is compiled with optimization. (You can argue calling stat with a NULL pointer is bad behavior, however this code has been in cronolog, working fine when compiled with -O2, for years). I can reproduce this easily on multiple systems, bionic with "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0" and xenial with "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609". I could not initially reproduce the cronolog testcase in xenial, leading me to some suspicion that it may be related to retpoline or other recent compiler changes - and in fact after recompiling cronolog on xenial I can reproduce the issue there as well.
2018-05-11 15:57:45 Scott Emmons description While investigating why cronolog was no longer changing a log symlink in bionic, I discovered a bug in gcc (reproducable in 7.3.0-16ubuntu3 in bionic and 5.4.0-6ubuntu1~16.04.9 in xenial) for code compiled with -O2. I have created a simple testcase to reproduce the problem, which is attached. You can reproduce the problem with the following: # ==== set -x echo "First, we compile and run without optimization:" gcc -o testcase testcase.c && ./testcase echo "Then, we compile and run with optimization:" gcc -O2 -o testcase testcase.c && ./testcase # ==== Which outputs: + echo 'First, we compile and run without optimization:' First, we compile and run without optimization: + gcc -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is NULL (expected) foo in main() is NULL (expected) foo in main() is NULL (expected) + echo 'Then, we compile and run with optimization:' Then, we compile and run with optimization: + gcc -O2 -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is not NULL (NOT EXPECTED!) foo in main() is NULL (expected) foo in main() is NULL (expected) The problem occurs after calling:   stat(foo, &stat_buf); Where foo is a NULL pointer. After the return from this function, foo will no longer be NULL when the code is compiled with optimization. (You can argue calling stat with a NULL pointer is bad behavior, however this code has been in cronolog, working fine when compiled with -O2, for years). I can reproduce this easily on multiple systems, bionic with "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0" and xenial with "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609". I could not initially reproduce the cronolog testcase in xenial, leading me to some suspicion that it may be related to retpoline or other recent compiler changes - and in fact after recompiling cronolog on xenial I can reproduce the issue there as well. While investigating why cronolog was no longer changing a log symlink in bionic, I discovered a bug in gcc (reproducable in 7.3.0-16ubuntu3 in bionic and 5.4.0-6ubuntu1~16.04.9 in xenial) for code compiled with -O2. I have created a simple testcase to reproduce the problem, which is attached. You can reproduce the problem with the following: # ==== set -x echo "First, we compile and run without optimization:" gcc -o testcase testcase.c && ./testcase echo "Then, we compile and run with optimization:" gcc -O2 -o testcase testcase.c && ./testcase # ==== Which outputs: + echo 'First, we compile and run without optimization:' First, we compile and run without optimization: + gcc -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is NULL (expected) foo in main() is NULL (expected) foo in main() is NULL (expected) + echo 'Then, we compile and run with optimization:' Then, we compile and run with optimization: + gcc -O2 -o testcase testcase.c + ./testcase foo in func() is NULL (expected) foo in func() is not NULL (NOT EXPECTED!) foo in main() is NULL (expected) foo in main() is NULL (expected) The problem occurs after calling:   stat(foo, &stat_buf); Where foo is a NULL pointer. After the return from this function, foo will no longer be NULL when the code is compiled with optimization - but only when the pointer is a function parameter of func(). The issue does not occur when the same codepath is called in main(). (You can argue calling stat with a NULL pointer is bad behavior, however this code has been in cronolog, working fine when compiled with -O2, for years). I can reproduce this easily on multiple systems, bionic with "gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0" and xenial with "gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609". I could not initially reproduce the cronolog testcase in xenial, leading me to some suspicion that it may be related to retpoline or other recent compiler changes - and in fact after recompiling cronolog on xenial I can reproduce the issue there as well.
2018-05-11 16:36:09 Launchpad Janitor gcc-5 (Ubuntu): status New Confirmed
2018-05-11 16:36:09 Launchpad Janitor gcc-7 (Ubuntu): status New Confirmed
2018-05-11 16:36:58 Patricia Gaughen bug added subscriber Patricia Gaughen
2018-05-14 18:46:05 Matthias Klose bug watch added https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85778
2018-05-14 18:46:05 Matthias Klose bug task added gcc
2018-05-14 22:18:27 Bug Watch Updater gcc: status Unknown New
2018-05-14 22:18:27 Bug Watch Updater gcc: importance Unknown Medium
2018-05-15 16:01:04 Matthias Klose bug task added cronolog (Ubuntu)
2018-05-15 16:01:13 Matthias Klose cronolog (Ubuntu): status New Confirmed
2018-05-15 16:01:18 Matthias Klose gcc-5 (Ubuntu): status Confirmed Invalid
2018-05-15 16:01:26 Matthias Klose gcc-7 (Ubuntu): status Confirmed Invalid
2018-05-15 16:13:03 Scott Emmons bug watch added https://github.com/fordmason/cronolog/issues/4
2018-05-15 17:13:55 Scott Emmons bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799170
2018-05-15 17:13:55 Scott Emmons bug task added cronolog (Debian)
2018-05-15 17:18:53 Scott Emmons summary gcc optimizer bug cronolog doesn't update links due to stat() on NULL pathname
2018-05-15 22:23:42 Bug Watch Updater cronolog (Debian): status Unknown New
2018-05-17 03:20:32 Bug Watch Updater gcc: status New Invalid