ssett / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

debugallocation_test.sh fails, but make 'check succeeds' on linux #661

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I was investigating why this test fails on FreeBSD and found that on Linux 
(Mint) it also misbehaves.

'make check' command on Linux succeeds 100%, but when the test 
'debugallocation_test.sh' is run individually, it says it fails Test#15 (like 
on FreeBSD).

That test says that it should pass when output is "@ .*main", but there is no 
word "main" in the output on Linux (same on BSD).

So there are two problems:
1. 'make check' doesn't catch the individual test failure on Linux
2. Test#15 looks for the condition that doesn't exist and fails wrongfully

Original issue reported on code.google.com by yuriv...@gmail.com on 10 Dec 2014 at 9:21

GoogleCodeExporter commented 9 years ago
Good work. Thanks. Should I expect patch for this issue ?

Original comment by alkondratenko on 10 Dec 2014 at 9:22

GoogleCodeExporter commented 9 years ago
About problem#1:
I was scratching my head why would test shell scripts behave differently on 
linux and BSD and now I see: bash.

Bash is quite unstable and varies in behavior on different systems. I saw many 
bugs in it, and reported several bugs to them. However, they refuse to even 
have the bug reporting system (!!!). So many of bug reports (including mine) 
end up in oblivion, and nobody really has the full list. I keep getting lost 
processes launched from bash scripts on my desktop fox ex., and lost temporary 
files created by bash. Given this state of affairs, and unreasonable complexity 
of bash scripts, I am not very motivated to spend time digging through them. 
And in the end, most likely I will end up finding some bug in bash itself, 
which will end up to never be fixed.

Someone should really rewrite the test scripts in Bourne shell, which is pretty 
much rock-solid stable and simple. Or maybe there is some ready solution for 
regression testing on the shell level.

Otherwise, tests will be fuzzy and iffy, and results will vary by platform, 
like they are now.

Original comment by yuriv...@gmail.com on 11 Dec 2014 at 1:05

GoogleCodeExporter commented 9 years ago
Tests actually pass under make check (on linux at least). You can see that by 
inspecting output of this log in debugallocation_test.sh.log

And was able to figure out why. It is because make check sets PPROF_PATH 
accordingly while debugallocation_test.sh does not.

Original comment by alkondratenko on 10 Jan 2015 at 10:24

GoogleCodeExporter commented 9 years ago
What you think about the following patch ? :

rom d2a60f1af77f6ba5ee1cadf62983bdfcf5b75918 Mon Sep 17 00:00:00 2001
From: Aliaksey Kandratsenka <alk@tut.by>
Date: Sat, 10 Jan 2015 14:29:59 -0800
Subject: [PATCH] issue-661: warn that debugallocation_test requires PPROF_PATH

Some debugallocation_test needs pprof be present so that stacktraces
can be symbolyzed. Under make check PPROF_PATH is set, but when
running this test manually it is not. So it is easy to incorrectly
conclude that make is not detecting test failure.
---
 src/tests/debugallocation_test.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/tests/debugallocation_test.sh 
b/src/tests/debugallocation_test.sh
index faa6c79..4997088 100755
--- a/src/tests/debugallocation_test.sh
+++ b/src/tests/debugallocation_test.sh
@@ -40,6 +40,10 @@ if [ "x$1" = "x-h" -o "x$1" = "x--help" ]; then
   exit 1
 fi

+if [ "x$PPROF_PATH" = "x" ]; then
+    echo "NOTE: that without \$PPROF_PATH set this test will likely fail."
+fi
+
 DEBUGALLOCATION_TEST="${1:-$BINDIR/debugallocation_test}"

 num_failures=0
-- 
2.1.4

Original comment by alkondratenko on 10 Jan 2015 at 10:32