What steps will reproduce the problem?
1. create a unit tests that contains
EXPECTS_DEATH(volatile int rc = strlen(NULL), "");
* Yes I know this is uninteresting, but it is equivalent to my real test which
asserts a memory mapped block has been released. *
2. Run that test.
What is the expected output? What do you see instead?
I expect that both the test passes and that nothing additional is left
behind. However, the spawned process is leaving behind a core dump.
What version of the product are you using? On what operating system?
Googletest v.1.3.0 on Linux 2.6.18-128.1.6.el5 (yes I know it's old... not
my choice)
Is there an easy way to prevent this without forcing my entire test suite to
prevent core dumps (which include legacy non-googletest based tests)?
Original issue reported on code.google.com by [email protected] on 21 Dec 2009 at 5:52
It's impossible for gtest to anticipate all possible side effects in a death
test and
clean them up. Instead, it's the test author's responsibility to ensure that
the
tests clean up after themselves. Some people may even find the core dump
useful.
Please try to rewrite your test to disable core dump. You can see 'man core'
on how
to do it.
Original comment by [email protected] on 21 Dec 2009 at 7:07
In case anyone else comes here looking for a solution I'll post what I've
decided to go
with.
This works on linux and is likely not portable:
Index: gtest-death-test.cpp
====================================================
===============
--- gtest-death-test.cpp (revision 60319)
+++ gtest-death-test.cpp (working copy)
@@ -990,6 +990,11 @@
// This function is called in a clone()-ed process and thus must avoid
// any potentially unsafe operations like malloc or libc functions.
static int ExecDeathTestChildMain(void* child_arg) {
+ rlimit core_limit;
+ core_limit.rlim_cur = 0;
+ core_limit.rlim_max = 0;
+ setrlimit(RLIMIT_CORE, &core_limit);
+
ExecDeathTestArgs* const args = static_cast<ExecDeathTestArgs*>(child_arg);
GTEST_DEATH_TEST_CHECK_SYSCALL_(close(args->close_fd));
Original comment by [email protected] on 21 Dec 2009 at 7:56
Most helpful comment
Original comment by
[email protected]on 21 Dec 2009 at 7:56