Commit Graph

64 Commits

Author SHA1 Message Date
Mike Fleetwood 03c2be9b90 Test that PipeCapture clears capture buffer before it starts (#777973)
Initialise capture string with sacrificial text before each test.
Existing tests confirm this is cleared first by checking the captured
string matches the input string.

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood 1e3324e16b Add test for bug with PipeCapture crashing reading binary data (#777973)
A user had a very corrupt FAT file system and fsck.fat was reporting
binary data in file names with errors.  GParted crashed reading this
output.  Boiled down the problematic fsck.fat output to a sample 27
bytes which still triggers a crash and created a test for it.  The test
crashes test_PipeCapture program too.

    $ ./test_PipeCapture
    ...
    [ RUN      ] PipeCaptureTest.MinimalBinaryCrash777973
    Segmentation fault (core dumped)
    $ echo $?
    139

However it still produces a non-zero exit status and the autotools test
runner detects this so 'make check' still reports failure.

    $ make check
    ...
    make[2]: Entering directory `/home/centos/programming/c/gparted/tests'
    PASS: test_dummy
    PASS: test_BlockSpecial
    ../test-driver: line 95: 16152 Segmentation fault      "$@" > $log_file 2>&1
    FAIL: test_PipeCapture
    ...
    ============================================================================
    Testsuite summary for gparted 0.28.1-git
    ============================================================================
    # TOTAL: 3
    # PASS:  2
    # SKIP:  0
    # XFAIL: 0
    # FAIL:  1
    # XPASS: 0
    # ERROR: 0
    ============================================================================
    See tests/test-suite.log
    Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted
    ============================================================================
    make[2]: *** [test-suite.log] Error 1
    make[2]: Leaving directory `/home/centos/programming/c/gparted/tests'
    make[1]: *** [check-TESTS] Error 2
    make[1]: Leaving directory `/home/centos/programming/c/gparted/tests'
    make: *** [check-am] Error 2
    $ echo $?
    2

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood 8b47de8872 Add check of PipeCapture update callback (#777973)
Also ensure that the PipeCapture calls registered update callbacks and
that the data so far captured matches the leading portion of the input.

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood dc1c49ba62 Add binary data string difference reporting to PipeCapture tests (#777973)
Google Test string comparison asserts are only designed of C style
strings containing printable text of one or more lines with a
terminating NUL character.  GParted is crashing when PipeCapture is
reading the binary file names being reported by fsck.fat from a very
corrupted FAT file system.  Therefore need to be able to compare and
report differences of binary data stored in C++ std::string and
Glib::ustrings.  Write a specific assertion to handle this.

Now these sample tests:

    TEST_F( PipeCaptureTest, BinaryStringFailure )
    {
        inputstr = "AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCC";
        capturedstr = "AAAAAAAAAAAAAAAABBBBBBBBBBbbbb";
        EXPECT_BINARYSTRINGEQ( inputstr, capturedstr.raw() );
    }

    TEST_F( PipeCaptureTest, LeadingBinaryStringFailure )
    {
        inputstr = "The quick brown fox jumps over the lazy dog";
        capturedstr = "The quick brown fox\n";
        EXPECT_BINARYSTRINGEQ( inputstr.substr( 0, capturedstr.raw().length() ),
                               capturedstr.raw() );
    }

report failure like this:

    $ ./test_PipeCapture
    ...

    [ RUN      ] PipeCaptureTest.BinaryStringFailure
    test_PipeCapture.cc:270: Failure
          Expected: inputstr
         Of length: 48
    To be equal to: capturedstr.raw()
         Of length: 30
    With first binary difference:
    < 0x00000010  "BBBBBBBBBBBBBBBB"  42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
    --
    > 0x00000010  "BBBBBBBBBBbbbb"    42 42 42 42 42 42 42 42 42 42 62 62 62 62
    [  FAILED  ] PipeCaptureTest.BinaryStringFailure (1 ms)
    [ RUN      ] PipeCaptureTest.LeadingBinaryStringFailure
    test_PipeCapture.cc:278: Failure
          Expected: inputstr.substr( 0, capturedstr.raw().length() )
         Of length: 20
    To be equal to: capturedstr.raw()
         Of length: 20
    With first binary difference:
    < 0x00000010  "fox "              66 6F 78 20
    --
    > 0x00000010  "fox."              66 6F 78 0A
    [  FAILED  ] PipeCaptureTest.LeadingBinaryStringFailure (0 ms)
    ...

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood eb2d571a6c Add 1 MiB ASCII PipeCapture test (#777973)
Add test sending 1 MiB of ASCII test into PipeCapture to read.  This
requires multiple reads and rewites through the pipe.

This is as much a check of the threading in the PipeCaptureTest class as
it is of PipeCapture itself.  This is because a single thread might
block reading from a pipe waiting for itself to write to the pipe.
Deadlock.  Hence the requirement to use a separate thread for reading
and writing.

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood d90702d526 Initialise Glib threading system in test_PipeCapture (#777973)
On CentOS 6, with glib/glibmm 2.28, running the tests fails thus:

    $ ./test_PipeCapture
    Running main() from gtest_main.cc
    [==========] Running 4 tests from 1 test case.
    [----------] Global test environment set-up.
    [----------] 4 tests from PipeCaptureTest
    [ RUN      ] PipeCaptureTest.EmptyPipe

    GLib-ERROR **: The thread system is not yet initialized.
    aborting...
    Aborted (core dumped)

For glib before version 2.32, the threading system must be explicitly
initialised with a call to g_thread_init(), or the Glibmm
Glib::thread_init() equivalent to prevent this error.

    Deprecated thread API, g_thread_init()
    https://developer.gnome.org/glib/stable/glib-Deprecated-Thread-APIs.html#g-thread-init

Do this by providing our own main() which also initialises the Glib
threading system, rather using and linking in the Google Test provided
main().

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood b21ee06230 Add initial unit tests for PipeCapture (#777973)
So far just tests sending 0 bytes and a few ASCII bytes into a pipe and
that they are read correctly by the PipeCapture class.

Bug 777973 - Segmentation fault on bad disk
2017-06-02 11:47:35 -06:00
Mike Fleetwood 72e81622f3 Improve diagnostics of failed BlockSpecial operator tests (#781978)
Deliberately breaking one of the operator<() tests produces less than
ideal diagnostics because it doesn't print the BlockSpecial objects
being compared.

    $ ./test_BlockSpecial
    ...
    [ RUN      ] BlockSpecialTest.OperatorLessThanTwoEmptyObjects
    test_BlockSpecial.cc:362: Failure
    Value of: bs1 < bs2
      Actual: true
    Expected: false
    [  FAILED  ] BlockSpecialTest.OperatorLessThanTwoEmptyObjects (1 ms)
    ...

This could be solved by using the Google Test Binary Comparison
assertions, however in the tests for false from (bs1 == bs2) and
(bs1 < bs2) comparisons then operators != and >= would have to be
implemented and the tests changed from:
    EXPECT_FALSE( bs1 < bs2 );
to:
    EXPECT_GE( bs1, bs2 );
This makes the meaning of the test less than clear.  The primary purpose
of the test is to check operator<(), but it is expecting the first
BlockSpecial object to be GE (greater than or equal to) than the second,
which is calling operator>=() which in turn is testing operator<().  For
tests of the operators themselves using Google Test Binary Comparison
assertions obscures what is being tested too much.

Instead provide a custom failure message which prints the BlockSpecial
objects failing the comparison, leaving the test still directly calling
the operator being tested, like this:
    EXPECT_FALSE( bs1 < bs2 ) << "   Where: bs1 = " << bs1 << "\n"
                              << "     And: bs2 = " << bs2;
And with a suitable macro this is simplified to:
    EXPECT_FALSE( bs1 < bs2 ) << ON_FAILURE_WHERE( bs1, bs2 );
Now the above deliberately broken test produces this output:

    $ ./test_BlockSpecial
    ...
    [ RUN      ] BlockSpecialTest.OperatorLessThanTwoEmptyObjects
    test_BlockSpecial.cc:369: Failure
    Value of: bs1 < bs2
      Actual: true
    Expected: false
       Where: bs1 = BlockSpecial{"",0,0}
         And: bs2 = BlockSpecial{"",0,0}
    [  FAILED  ] BlockSpecialTest.OperatorLessThanTwoEmptyObjects (0 ms)
    ...

Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:47:35 -06:00
Mike Fleetwood 003d1b54c7 Add BlockSpecial operator<() tests (#781978)
Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:47:35 -06:00
Mike Fleetwood f4008092dd Add test for bug #771670 in BlockSpecial::operator==() (#781978)
Add a specific test for the failure found in bug 771670 and fixed by
commit:
    253c4d6416
    Fix BlockSpecial comparison (#771670)

Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:47:35 -06:00
Mike Fleetwood debbd811b8 Add BlockSpecial operator==() tests (#781978)
Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:47:35 -06:00
Mike Fleetwood c37be28148 Add unit tests for BlockSpecial constructors and internal caching (#781978)
So far only includes tests of the construction of BlockSpecial objects
and the interaction with the internal cache used to reduce the number of
stat(2) calls.  Tests have been designed to be runable by non-root users
and assume as little as possible about the environment by discovering
used block device names and symbolic link name.

Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:47:30 -06:00
Mike Fleetwood dbd5cd2ca8 Fix make distcheck failure from missing libgtest_main.la (#781978)
Running 'make distcheck' fails like this:
    [...]
    make[3]: Entering directory `[...]/gparted/gparted-0.28.1-git/_build/tests'
    [...]
    /bin/sh ../libtool --tag=CXX --mode=link g++ [...] ../../lib/gtest/lib/libgtest_main.la ../../lib/gtest/lib/libgtest.la [...]
    libtool: link: cannot find the library `../../lib/gtest/lib/libgtest_main.la' or unhandled argument `../../lib/gtest/lib/libgtest_main.la'
    make[3]: *** [test_dummy] Error 1
    make[3]: Leaving directory `[...]/gparted/gparted-0.28.1-git/_build/tests'
    [...]
    make[1]: Leaving directory `[...]/gparted/gparted-0.28.1-git/_build'
    make: *** [distcheck] Error 1

What is happening is that distcheck [1] performs a VPATH build which
uses separate read-only source and read-write build trees.  Shipped
source files, such as .h and .cc, are located in the source tree and the
built files, such as .o and .la, are compiled into the build tree.  In
this case the absolute path to libgtest_main.la is specified using
$(top_srcdir) for the source tree, rather than $(top_builddir) for the
build tree, hence the cannot find file type error.  This error doesn't
occur when just performing a 'make check' because that builds in the
source tree so $(top_builddir) is the same as $(top_srcdir).

Fix by correctly specifying the absolute path to the libgtest*.la files
using $(top_builddir).

[1] Automake Manual, 14.4 Checking the Distribution
    https://www.gnu.org/software/automake/manual/automake.html#Checking-the-Distribution

Note that for VPATH builds the Automake Manual [2] also recommends using
a pair of -I options to specify header files are found in both the build
and source trees, something like:
    AM_CPPFLAGS = -I$(top_builddir)/some/subdir -I$(top_srcdir)/some/subdir

This is unnecessary for GParted as all header files are shipped as part
of the source archive and no header files are created as part of the
build process.  Therefore adding -I options specifying $(top_builddir)
include directories would just be specifying empty or non-existent
include directories in the build tree.

[2] Automake Manual, 8.7 Variables used when building a program
    https://www.gnu.org/software/automake/manual/automake.html#Program-Variables

Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:13:16 -06:00
Mike Fleetwood dceb293f15 Add unit test suites with initial successful dummy test (#781978)
Now 'make check' will additionally build and run the test suites in the
./tests directory.  Add initial always successful dummy test suite.
This is done using Automake support for testing.

    Automake Manual, 15 Support for test suites
    https://www.gnu.org/software/automake/manual/automake.html#Tests

./tests/Makefile.am takes some influence from the same file in the
minimal-gtest-autotools template project.
    654848ec01/tests/Makefile.am

Bug 781978 - Add Google Test C++ test framework
2017-06-02 10:13:16 -06:00