Activity log for bug #1027977

Date Who What changed Old value New value Message
2012-07-23 14:45:55 Moritz Hassert bug added bug
2012-07-23 14:45:55 Moritz Hassert attachment added minimal test case https://bugs.launchpad.net/bugs/1027977/+attachment/3232950/+files/strstrtest.c
2012-07-23 15:01:30 Moritz Hassert bug watch added https://bugs.kde.org/show_bug.cgi?id=303963
2012-07-23 17:31:52 Julian Taylor bug task added valgrind
2012-07-25 11:13:14 Bug Watch Updater valgrind: status Unknown Fix Released
2012-07-25 11:13:14 Bug Watch Updater valgrind: importance Unknown Medium
2012-07-26 09:00:38 Moritz Hassert valgrind (Ubuntu): status New Confirmed
2012-07-27 16:21:38 Moritz Hassert attachment added adapted version of upstream patch https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1027977/+attachment/3238831/+files/fix-VEX-PCMPxSTRx.patch
2012-07-27 16:27:16 Ubuntu Foundations Team Bug Bot tags patch
2012-07-27 16:27:24 Ubuntu Foundations Team Bug Bot bug added subscriber Ubuntu Review Team
2012-07-27 16:28:39 Moritz Hassert attachment added Output of debdiff including my previous patch https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1027977/+attachment/3238841/+files/debdiff-fix-VEX-PCMPxSTRx.patch
2012-10-05 18:16:17 Julian Taylor valgrind (Ubuntu): assignee Julian Taylor (jtaylor)
2012-10-05 20:33:50 Launchpad Janitor branch linked lp:~jtaylor/ubuntu/quantal/valgrind/various-fixes
2012-10-05 20:42:01 Julian Taylor valgrind (Ubuntu): assignee Julian Taylor (jtaylor)
2012-10-05 20:53:56 Julian Taylor bug added subscriber Julian Taylor
2012-10-06 00:45:18 Launchpad Janitor valgrind (Ubuntu): status Confirmed Fix Released
2012-10-06 01:33:57 Launchpad Janitor branch linked lp:ubuntu/valgrind
2012-10-10 11:48:39 Moritz Hassert description $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux EDIT: adapted description according to SRU Bug Template [IMPACT] * impact on users: Profiling an application with callgrind produces false results: The application silently changes behavior because of false strstr() results in certain cases. * justification for backporting the fix to the stable release: - 12.04 is a LTS release. Lots of people installed it for that very reason and intend to stick with it until the next LTS release. Especially as this bug affects mainly software developers and in professional environments the upgrade cycles are longer. Those people will not benefit from a fix in the upcoming release. - The patch is very small and local. - There is no danger in backporting it (see Regression Potential below). - The fix is already in 12.10 and could be taken directly from there without any hassle. * The emulation of a certain SSE4-instruction in the valgrind package in 12.04 is flawed. This bug is fixed by a patch made by the upstream author. [TESTCASE] When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. [Regression Potential] * I don't see any danger of regressions. There is no change in behavior other than correcting false behavior in one place. No other applications depend on valgrind/callgrind, especially nothing that a normal user or server administrator ever uses. * I've been using the patched version for 2 months now without any problems. * If this should introduce any sort of regression, it will only affect valgrind/callgrind itself and no other parts of the system. --- Old description: $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
2012-10-10 18:30:48 Julian Taylor nominated for series Ubuntu Precise
2012-10-10 18:33:08 Julian Taylor bug added subscriber Ubuntu Sponsors Team
2012-10-10 18:35:16 Julian Taylor description EDIT: adapted description according to SRU Bug Template [IMPACT] * impact on users: Profiling an application with callgrind produces false results: The application silently changes behavior because of false strstr() results in certain cases. * justification for backporting the fix to the stable release: - 12.04 is a LTS release. Lots of people installed it for that very reason and intend to stick with it until the next LTS release. Especially as this bug affects mainly software developers and in professional environments the upgrade cycles are longer. Those people will not benefit from a fix in the upcoming release. - The patch is very small and local. - There is no danger in backporting it (see Regression Potential below). - The fix is already in 12.10 and could be taken directly from there without any hassle. * The emulation of a certain SSE4-instruction in the valgrind package in 12.04 is flawed. This bug is fixed by a patch made by the upstream author. [TESTCASE] When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. [Regression Potential] * I don't see any danger of regressions. There is no change in behavior other than correcting false behavior in one place. No other applications depend on valgrind/callgrind, especially nothing that a normal user or server administrator ever uses. * I've been using the patched version for 2 months now without any problems. * If this should introduce any sort of regression, it will only affect valgrind/callgrind itself and no other parts of the system. --- Old description: $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux EDIT: adapted description according to SRU Bug Template [IMPACT]  * impact on users: Profiling an application with callgrind produces false results: The application silently changes behavior because of false strstr() results in certain cases.  * justification for backporting the fix to the stable release: - 12.04 is a LTS release. Lots of people installed it for that very reason and intend to stick with it until the next LTS release. Especially as this bug affects mainly software developers and in professional environments the upgrade cycles are longer. Those people will not benefit from a fix in the upcoming release. - The patch is very small and local. - There is no danger in backporting it (see Regression Potential below). - The fix is already in 12.10 and could be taken directly from there without any hassle.  * The emulation of a certain SSE4-instruction in the valgrind package in 12.04 is flawed. This bug is fixed by a patch made by the upstream author. The debdiff of 1:3.7.0-0ubuntu4 can and should be backported without change to precise. The other fixed issue is also SRU material, see bug 1036283 [TESTCASE] When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. [Regression Potential]  * I don't see any danger of regressions. There is no change in behavior other than correcting false behavior in one place. No other applications depend on valgrind/callgrind, especially nothing that a normal user or server administrator ever uses. * I've been using the patched version for 2 months now without any problems. * If this should introduce any sort of regression, it will only affect valgrind/callgrind itself and no other parts of the system. --- Old description: $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
2012-10-10 18:44:15 Julian Taylor attachment added sru debdiff https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1027977/+attachment/3393551/+files/valgrind.debdiff.gz
2012-10-10 18:45:57 Julian Taylor description EDIT: adapted description according to SRU Bug Template [IMPACT]  * impact on users: Profiling an application with callgrind produces false results: The application silently changes behavior because of false strstr() results in certain cases.  * justification for backporting the fix to the stable release: - 12.04 is a LTS release. Lots of people installed it for that very reason and intend to stick with it until the next LTS release. Especially as this bug affects mainly software developers and in professional environments the upgrade cycles are longer. Those people will not benefit from a fix in the upcoming release. - The patch is very small and local. - There is no danger in backporting it (see Regression Potential below). - The fix is already in 12.10 and could be taken directly from there without any hassle.  * The emulation of a certain SSE4-instruction in the valgrind package in 12.04 is flawed. This bug is fixed by a patch made by the upstream author. The debdiff of 1:3.7.0-0ubuntu4 can and should be backported without change to precise. The other fixed issue is also SRU material, see bug 1036283 [TESTCASE] When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. [Regression Potential]  * I don't see any danger of regressions. There is no change in behavior other than correcting false behavior in one place. No other applications depend on valgrind/callgrind, especially nothing that a normal user or server administrator ever uses. * I've been using the patched version for 2 months now without any problems. * If this should introduce any sort of regression, it will only affect valgrind/callgrind itself and no other parts of the system. --- Old description: $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux EDIT: adapted description according to SRU Bug Template [IMPACT]  * impact on users: Profiling an application with callgrind produces false results: The application silently changes behavior because of false strstr() results in certain cases.  * justification for backporting the fix to the stable release: - 12.04 is a LTS release. Lots of people installed it for that very reason and intend to stick with it until the next LTS release. Especially as this bug affects mainly software developers and in professional environments the upgrade cycles are longer. Those people will not benefit from a fix in the upcoming release. - The patch is very small and local. - There is no danger in backporting it (see Regression Potential below). - The fix is already in 12.10 and could be taken directly from there without any hassle.  * The emulation of a certain SSE4-instruction in the valgrind package in 12.04 is flawed. This bug is fixed by a patch made by the upstream author. The debdiff of 1:3.7.0-0ubuntu4 can and should be backported without change to precise. The other fixed issue is also SRU material, see bug 1036283 debdiff in comment 26 [TESTCASE] When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. [Regression Potential]  * I don't see any danger of regressions. There is no change in behavior other than correcting false behavior in one place. No other applications depend on valgrind/callgrind, especially nothing that a normal user or server administrator ever uses. * I've been using the patched version for 2 months now without any problems. * If this should introduce any sort of regression, it will only affect valgrind/callgrind itself and no other parts of the system. --- Old description: $valgrind --version valgrind-3.7.0 When an application that uses the strstr() function from the C standard library is profiled with valgrind --tool=callgrind, the strstr() function produces false results (at least) under the following conditions: * the string s1 to search in and the string s2 to search for are exact duplicates, that is strcmp(s1,s2)==0. s1 and s2 don't need to be pointing to the same memory object. * the string length (excluding terminating zero) is a multiple of 16 Expected result: strstr(s1,s2) returns s1, indicating a match at the first charactor of s1 What happens: strstr(s1,s2) returns NULL, indicating no matching substring was found. See attached minimal testcase for an example. Reproduce under Ubuntu 12.04 with the following steps: $gcc strstrtest.c -o strstrtest $./ strstrtest # <-- should report no errors $valgrind --tool=callgrind ./ strstrtest # <-- should report errors for lengths multiple of 16 - The Problem does not show up under valgrind-3.6.0.SVN-Debian from Ubuntu 10.04 Lucid Lynx - The Problem does not show up under tool=memcheck. Some more info: OS: Ubuntu 12.04 Precise Pangolin $uname -a Linux mhassert 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
2012-10-19 16:42:09 Micah Gersten bug task added valgrind (Ubuntu Precise)
2012-11-27 11:44:37 Sebastien Bacher valgrind (Ubuntu Precise): importance Undecided Low
2012-11-27 11:44:40 Sebastien Bacher valgrind (Ubuntu Precise): status New Triaged
2012-11-27 18:31:43 Julian Taylor attachment added valgrind-sru.debdiff https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1027977/+attachment/3445300/+files/valgrind-sru.debdiff
2012-12-05 16:18:37 Marc Deslauriers removed subscriber Ubuntu Sponsors Team
2012-12-05 16:18:45 Marc Deslauriers bug added subscriber Ubuntu Stable Release Updates Team
2012-12-05 16:18:57 Marc Deslauriers nominated for series Ubuntu Quantal
2012-12-05 16:18:57 Marc Deslauriers bug task added valgrind (Ubuntu Quantal)
2012-12-05 16:19:05 Marc Deslauriers valgrind (Ubuntu Quantal): status New Fix Released
2013-01-26 00:06:59 Steve Langasek valgrind (Ubuntu Precise): status Triaged Fix Committed
2013-01-26 00:07:03 Steve Langasek bug added subscriber SRU Verification
2013-01-26 00:07:06 Steve Langasek tags patch patch verification-needed
2013-01-26 00:50:28 Launchpad Janitor branch linked lp:ubuntu/precise-proposed/valgrind
2013-03-21 19:16:42 Philip Wyett tags patch verification-needed patch verification-done-precise verification-needed
2013-03-22 10:01:30 Philip Wyett tags patch verification-done-precise verification-needed patch verification-done-precise
2013-03-22 12:35:09 Philip Wyett bug added subscriber Philip Wyett
2013-03-27 00:28:55 Chris Halse Rogers removed subscriber Ubuntu Stable Release Updates Team
2013-03-27 00:29:13 Launchpad Janitor valgrind (Ubuntu Precise): status Fix Committed Fix Released