search

tr00per / googletest

Automatically exported from code.google.com/p/googletest
0 stars 0 forks source link

no way to delete UnitTest instance #62

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. call InitGoogleTest
2. call RUN_ALL_TESTS()
3. run leak checking code

What is the expected output? What do you see instead?

The UnitTest object, as well as the result_printer and perhaps others
aren't and cannot be freed. It's also not possible to create all of these
objects before tests are running so it's a hassle to do leak checking.

What version of the product are you using? On what operating system?

1.1.0, Windows.

Original issue reported on code.google.com by sgraham on 8 Nov 2008 at 9:58

GoogleCodeExporter commented 9 years ago

Original comment by shiq...@gmail.com on 11 Nov 2008 at 6:47

GoogleCodeExporter commented 9 years ago 
We considered the following approaches:

1. let RUN_ALL_TESTS() cleans up all gtest data structures before it returns.
2. provide a CleanGoogleTest() function the user can call after RUN_ALL_TESTS().

#1 is less work for new users, but will break many existing users who call 
RUN_ALL_TESTS() more than once for various reasons.

#2 means the UnitTest object needs to be allocated on the heap.  This might 
break 
some existing users who already use a leak checker that ignores static global 
objects 
but not heap-allocated objects.

We need to think more about this.

Original comment by shiq...@gmail.com on 2 Dec 2008 at 5:31

GoogleCodeExporter commented 9 years ago

Original comment by w...@google.com on 6 Mar 2010 at 6:05

GoogleCodeExporter commented 9 years ago 
Reopening per user request.

I think a safe way to introduce the change is to keep the existing
behavior of RUN_ALL_TESTS() unchanged, and add a new function
testing::RunAllTestsAndBeDone() to run the tests *and* delete the
UnitTest singleton.  People caring about space leak checking can call
this new function instead of RUN_ALL_TESTS().

Original comment by w...@google.com on 24 Mar 2010 at 9:55

GoogleCodeExporter commented 9 years ago 

A problem you should be aware of. 

I changed gtest.cc to delete the impl_ static object at end of job so I could 
use a
leak finder. It worked great, except when a death test was used. The leak 
finder was
called for every EXPECT_EXIT. And since the program terminated without the usual
exits to the functions, it showed leaks for all strings and other STL objects 
that
had been used. It is usually not practical to go thru all the normal exits when 
a
program is abnormally terminated. Also, there cannot be any outstanding 
allocated
memory or global variables in the test program, or they will also be reported as
leaks at this point.

The only way I found around it was to bypass the EXPECT_EXIT tests with a
preprocessor directive when the leak detector was used. This way, when the 
program
exited with the normal end of job, all leaks disappeared.

Even with this problem I think it is worth it to make this change. All required
changes to bypass the leak detector will be  in the test program. Making 
changes to
gtest itself is not necessary. Also the death tests are for exceptions that 
should
rarely, if ever, occur in normal processing. They can be tested when running 
without
the leak detector.

Original comment by jim...@email.com on 9 Apr 2010 at 8:24

GoogleCodeExporter commented 9 years ago 
There is also global strings (in testing::flags) that cause hassle for leak 
detectors. 
They're allocated pre-main, and modified by GTestFlagSaver during the execution 
of 
tests.

This makes gtest impractical to use with standard Windows SDK crtdbg.h leak 
tracking, 
which is unfortunate.

Original comment by sgraham on 3 May 2010 at 8:07