'make check' reports several failures about googletest HOT 13 CLOSED

BTW: file gtest_xml_output_unittest.py, function _TestXmlOutput() has part of 
code
similar to my proposal:

  def _TestXmlOutput(self, gtest_prog_name, expected_xml, expected_exit_code):
  ...
    command = ("%s %s=xml:%s &> /dev/null"
               % (gtest_prog_path, GTEST_OUTPUT_FLAG, xml_path))
    status = os.system(command)
    signal = status & 0xff
    self.assertEquals(0, signal,
                      "%s was killed by signal %d" % (gtest_prog_name, signal))
    exit_code = status >> 8
    self.assertEquals(expected_exit_code, exit_code,
                      "'%s' exited with code %s, which doesn't match "
                      "the expected exit code %s."
                      % (command, exit_code, expected_exit_code))
    ...

This is fixed in trunk and release-1.0.1.

I am using Ubuntu 8.04 and googletest 1.0.1 and I still get the described error 
while
trying to "make check". I am attaching stderr and stdout from make check.

I have:

$ uname -m
i686

$ uname -r
2.6.24-19-generic

$ uname -s
Linux

$ python -V
Python 2.5.2

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release 
--build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

I can confirm the bug on my Ubuntu 8.04 in v1.0.1. The problem is in handling
-gtest-output flag.

When -gtest-output=xml:out_name is specified, gtest_xml_outfiles_test.py 
expects the
binary (gtest_xml_outfile1_test_ or gtest_xml_outfile2_test_) to create file
gtest_xml_outfile1_test_.xml in the directory named out_name. Instead, the 
binary
tries to create the file named out_name (in the current directory if out_name is
relative path) and put the output there.

This is disconnect between the binary and the testing script and it is in 
1.0.1. I am
reopening the bug. Please mark it fixed again if it is fixed post 1.0.1.

I still cannot repro it on my Ubunto machine. :-(

The error log from renatoppl says:

AssertionError:
'/home/renatoppl/Downloads/gtest-1.0.1/test/gtest_xml_output_unittest_
--gtest_output=xml:/tmp/tmpmOmdlc/gtest_xml_output_unittest_out.xml &> 
/dev/null'
exited with code 0, which doesn't match the expected exit code 1.

gtest_xml_output_unittest.py does this:

    status = os.system(command)
    signal = status & 0xff
    self.assertEquals(0, signal,
                      "%s was killed by signal %d" % (gtest_prog_name, signal))
    exit_code = status >> 8
    self.assertEquals(expected_exit_code, exit_code,
                      "'%s' exited with code %s, which doesn't match "
                      "the expected exit code %s."
                      % (command, exit_code, expected_exit_code))

This matches the documentation for os.system() and works fine on my Ubuntu 
machine.

Vlad, since you can repro the bug on your machine, can you investigate it?

I don't think it has to do with the handling of -gtest_output.  I double 
checked the
code and found no mismatch between gtest_xml_outfiles_test.py and
gtest_xml_outfile1_test_.  Depending on whether out_name ends with "/", 
out_name is
treated either as the output file name or the directory that contains the output
file.  In either case, both the .py and the .cc treat it consistently.

The exit code problem *should* be fixed in the trunk now.  The fix will be in 
release
1.1.0.

I still cannot repro the xml-output-file-not-found problem.

Sorry - I got ahead of myself.  The fix mentioned in the previous comment 
hasn't been
checked in to the trunk yet.  It is still being reviewed, and should be checked 
in soon.

User Pete Johns reported on Aug 9, 2008:

Thanks Vlad.

I took a look at your comment on the bug <http://code.google.com/p/
googletest/issues/detail?id=9&q=xml#c4>, but you do not seem to be
describing the problem that I am experiencing. The file
(output_file_name2) *is* written in the correct directory
(output_dir_), but it is not ready for reading when the assertion is
called.

The following patch highlights the problem by waiting (and printing
dots) until the file appears.

If I get a chance to fix this over the weekend, I shall submit a
patch. I can confirm that the problem is the same on both Ubuntu and
Solaris.

Best;


--paj

Index: gtest_xml_outfiles_test.py
===================================================================
--- gtest_xml_outfiles_test.py  (revision 78)
+++ gtest_xml_outfiles_test.py  (working copy)
@@ -114,6 +114,8 @@
    output_file1 = os.path.join(self.output_dir_, output_file_name1)
    output_file_name2 = 'lt-' + output_file_name1
    output_file2 = os.path.join(self.output_dir_, output_file_name2)
+    while not (os.path.isfile(output_file1) or
os.path.isfile(output_file2)):
+        print '.',
    self.assert_(os.path.isfile(output_file1) or
os.path.isfile(output_file2),
                 output_file1)

Vlad reported that he can repro the bug on his machine at work.

I can confirm the problem still present in the latest version of Google Test on 
my
Ubuntu Hardy box with python 2.5.2, although it doesn't show up on a Dapper box 
with
python 2.4.3. Three tests fail:
test/gtest_break_on_failure_unittest.py
test/gtest_xml_output_unittest.py
test/gtest_xml_outfiles_test.py

In gtest_break_on_failure_unittest.py, the Run() function appears to always 
return
true. I can confirm that on Hardy os.WIFSIGNALED() never returns True in this 
test.
It is ither broken or used incorrectly.

In the other two tests, the files expected from the child process do not exist 
when
the script checks for their existence or tries to open them. But it is there 
when I
look it up later. Apparently the child process is still not done when 
os.system()
returns.  Has anyone else encountered it?

Issue 52 has been merged into this issue.

Some news on this issue. I have patches for two of the three failures. The 
reason
tuned out to be the use of "2>&1 &>/dev/null". On most Ubuntu systems, /bin/sh 
is
symlinked to /bin/bash. On Hardy, /bin/sh is symlinked to /bin/dash. Dash 
doesn't
understand &> construct (which is a bashism) and iterprets & separately, 
considering
it an instruction to execute program in the background. As a result, the python
script receives control and tries to inspect files before the test binary 
executes
ong enough to create them. The fixes are in revision 135.

The third failure is still not solved, so I'm leaving the bug open.

The issue finally fixed in release 1.2.0. The third problem was due to the way 
dash
behaved when python executed OS.system(). It was spawning an extra child 
process to
run the command which resulted in the signal termination status code being lost.