1

I decided to try writing tests with Catch. I am using MinGW32 in Windows. I used the example file define here (which I reproduce below for convenience):

#define CATCH_CONFIG_MAIN  // This tells Catch to provide a main() - only do this in one cpp file
#include "catch.hpp"

unsigned int Factorial( unsigned int number ) {
    return number <= 1 ? number : Factorial(number-1)*number;
}

TEST_CASE( "Factorials are computed", "[factorial]" ) {
    REQUIRE( Factorial(1) == 1 );
    REQUIRE( Factorial(2) == 2 );
    REQUIRE( Factorial(3) == 6 );
    REQUIRE( Factorial(10) == 3628800 );
}

I am running the following line to compile the program:

g++ -I./Catch/include/ -W -Wall -o run_tests main.cpp

I get absolutely no error, but when I run it I get a Segmentation Fault.

Following this, I tried supplying my own main() function. Now the code looks like this:

#define CATCH_CONFIG_RUNNER
#include "catch.hpp"

int main()
{
        return 0; // Yes, I'm not even using Catch and it still crashes
}

and I still get a Segmentation Fault.

Is this some incompatibility with MinGW? Has anyone also run into this issue?

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
vaulttech
  • 493
  • 1
  • 5
  • 15
  • 1
    Pardon the obvious next question: Does stripping out the macro and `#include`, pulling the include path from the cmdline, compiling, and running, *not* fault (i.e. there is no spoon)? Gotta start somewhere; may as well be there. – WhozCraig Aug 15 '16 at 22:59
  • I had not tried it =) But I just ran it. No segmentation fault. Without Catch, I can even call something like `printf("blah\n")` and it works normally. – vaulttech Aug 15 '16 at 23:13
  • Code Compiles != Code Runs Without Error. That said, run it through the debugger. It should halt at the segfault and give you an idea what top secret code Catch is hiding from your sight. – user4581301 Aug 15 '16 at 23:13
  • I ran `gdb run_tests` and then `start` (I don't know how to use it well), and it showed some `New Thread` lines and then something interesting: `Program received signal SIGSEGV, Segmentation fault.`, followed by a line with `0x6fc89111 in libstdc++-6!_ZNSsC1EPKcRKSaIcE ()` and `from C:\Python27\gnuplot\binary\libstdc++-6.dll`. Now I am trying to find out where Windows searches for its shared libraries. – vaulttech Aug 15 '16 at 23:24
  • Yes... this was the problem. I changed PATH so that the MinGW folder appeared before Python in the list, and now it works. Is this something serious? I am asking myself if this will have consequences to Python (it seems to be running fine now, but I totally don't know) – vaulttech Aug 15 '16 at 23:28
  • Have to say, that wasn't what I expected you'd find. I would have put money on some hidden static initialization that was done out-of-order. Watch out now, though. You might have just broken gnuplot. – user4581301 Aug 16 '16 at 00:22

0 Answers0