Memory segmentation fault in the end of running gtest

[Jorge Costa]

Hi,

I have a big problem. I have several dlls which contain inside gtest tests. These ones are run by a exec project pulling the test using the method describe in gtest primer (notes for visual c++ user) using gtest as shared library. 

This is the scenario: i have a common dll that contains tests. Then i have a specific dll that also contains tests, the specific dll at runtime uses the common dll. For each dll i have  a main executable project that should run the tests for each dll. 

So now the problem.

1> When running the executable from the specific dll both tests from common and specific are run. This is a problem since i want to measure the coverage of each dll individually, so the specific dll tests will cover more that actually does since those tests in common are running. So my idea would be to try to group the tests using some existent gtest feature that i dont find and then run test by group. I wouldn't like to have to have all tests starting with a prefix and then use ::testing::GTEST_FLAG(filter) += ":-:PREFIX_*"; since its another thing that developers need to remember when writing tests. 

2> i have another case where i have the tests in main exec project, then at runtime this project loads a specific dll that references the common dll above. In this case the specific dll does not have any tests (since they are part of the executable) however linking with shared libs makes the program crash since its trying to delete tests from common that haven't run (in the delete factory below). In this case i have a good workaround and i just use static libs and its fine. But a bit strange that first the test are not run and gtest is trying to clean them in the end.  

So in conclusion my main problem is to try to run tests per dll rather than having Gtest run all the test it finds. As for the second and subject would be good to have gtest more robust these cases.

Thanks in advance

Jorge Costa

// TODO(vl...@google.com): Make a_test_case_name and a_name const string&'s

// to signify they cannot be NULLs.

TestInfo::TestInfo(const char* a_test_case_name,

                   const char* a_name,

                   const char* a_type_param,

                   const char* a_value_param,

                   internal::TypeId fixture_class_id,

                   internal::TestFactoryBase* factory)

    : test_case_name_(a_test_case_name),

      name_(a_name),

      type_param_(a_type_param ? new std::string(a_type_param) : NULL),

      value_param_(a_value_param ? new std::string(a_value_param) : NULL),

      fixture_class_id_(fixture_class_id),

      should_run_(false),

      is_disabled_(false),

      matches_filter_(false),

      factory_(factory),

      result_() {}

// Destructs a TestInfo object.

TestInfo::~TestInfo() { delete factory_; }

[Vlad Losev]

My advice is don't put your tests in a library. Libraries's purpose is to facilitate code reuse. Their use comes with costs (you are bumping against them), although usually benefits of code reuse outweigh the costs. But I have yet to see a case where where reusing tests was required. So put your test into executables. If you want to group your tests, write a script that runs multiple executables and reports the combined result.

HTH,

Vlad

[Jorge Costa]

HI Vlad,

I also agree with you, however we have huge amount of tests that are defined in static libs and actually inside shared dll. Most of these are not possible to code outside the dll since the interfaces are not available. So this is something that we cant overcome. Linking those dlls against gtest static libs does not to work due to duplicate definitions coming from gtest and windows libs (! i think its a know issue).  

The reuse of the tests in my case is an undesired affect of having them in dlls. I was more asking if there is a way of grouping the tests inside the dll in a way that the filtering will pick them up and only run the tests that are in the dll under test. At this point im naming all the tests with a prefix per dll, so the script will run the correct tests. This is something that i would like to avoid but if there is no alternative then i will use this approach.

BR,

JC

[Vlad Losev]

On Mon, Apr 16, 2012 at 12:37 PM, Jorge Costa <jmec...@gmail.com> wrote:

HI Vlad,

I also agree with you, however we have huge amount of tests that are defined in static libs and actually inside shared dll. Most of these are not possible to code outside the dll since the interfaces are not available. So this is something that we cant overcome. Linking those dlls against gtest static libs does not to work due to duplicate definitions coming from gtest and windows libs (! i think its a know issue).

You can try building your code in static libs specifically for the purpose of testing - or even link it directly into test binaries. 

The reuse of the tests in my case is an undesired affect of having them in dlls. I was more asking if there is a way of grouping the tests inside the dll in a way that the filtering will pick them up and only run the tests that are in the dll under test. At this point im naming all the tests with a prefix per dll, so the script will run the correct tests. This is something that i would like to avoid but if there is no alternative then i will use this approach.

Alas, there is no way to auto-prefix test names that I know of.