-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: --gtest_break_on_failure conflicts with EXPECT_NONFATAL_FAILURE #4294
Comments
Hi, I'd like to work on this issue. |
@bklarson @derekmauro Break on failure seems to currently break on both regular failure and non fatal failure. If this is was not the intended design, all you have to do is to add the missing check in gtest.cc:5354:
It now doesn't break (SIGTRAP) for non-fatal failure. The question is then if this is the correct behavior for throw_on_failure, to also ignore non fatal failures. Using --gtest_throw_on_failure not throw with the above condition. Otherwise we need to move the condition to the line: |
Does this proposed solution pass all the tests locally (such as this one)? |
@higher-performance the googletest-throw-on-failure-test_.cc and googletest-break-on-failure-unittest_.cc are excluded from the regular test build process in the build script. All the non-excluded tests pass. The break-on-failure test fails (expected) and produces all output (doesn't seem to do much on non-Windows machines), while the throw-on-failure test just says "Failure" and then output is interrupted due to the throw (expected). I don't see "Unhandled C++ exception terminating the program.", but probably because stderr is not printed by default. |
Thanks for the reply. It's been a while since I looked at this issue, but I'm skeptical the solution is this simple... but perhaps I'm missing something? If this is the solution, then existing tests should all pass. (Unless they're buggy, in which case those bugs should be fixed.) I'm not entirely sure what you mean by failures being "expected" here, but it sounds to me like this would make some current tests start failing, which sounds to me like this breaks something, which in any case we don't want. So if you do see failures, they'd need to be addressed before we can consider this solution? If I misunderstood something let me know - I've lost some context since looking at this earlier. P.S. How does the |
You misunderstood. Some tests are intended to fail or have non-standard behavior, that is probably why they are in the exclusion list in the bazel build. Only the break one fails, the throw tests succeeds, despite the failure. So far as I can tell, the behavior I have seen for the previously mentioned two tests is ok. The solution is indeed simple. There is a separate state for non-fatal failures. The same happens for gtest_throw_on_failure_ex_test.cc. Here is the output:
This is expected since: And here is the output for googletest-throw-on-failure-test_:
For reference, here is the exclusion list:
|
Actually I think the TerminateHandler is not called for googletest-throw-on-failure-test_, which is a problem. I get the same behavior, regardless of whether GTEST_HAS_EXCEPTIONS is used. I think the flag is missing: GTEST_FLAG_SET(throw_on_failure, true); Again, all the tests on the non-exclusion list pass - 408 tests run, 407 tests passed 1 skipped |
Actually there is indeed a problem, with my code, the gtest_throw_on_failure_ex_test catches it. The other one is missing the flag. We need to add GTEST_FLAG_SET(throw_on_failure, true); to fix the test. Let me know if you agree. I changed the code so that it only impacts the break_on_failure condition and now both tests behave correctly (after amending the test):
Shouldn't we need a new test for this? The googletest-break-on-failure-unittest_ doesn't seem to be doing what is required for this bug (I tested manually using a new test according to OP's godbolt). |
…t throw_on_failure. Updated googletest-throw-on-failure-test_.cc to set the throw_on_failure mode.
…t throw_on_failure. Updated googletest-throw-on-failure-test_.cc to set the throw_on_failure mode.
…t throw_on_failure. Updated googletest-throw-on-failure-test_.cc to set the throw_on_failure mode.
At the moment I'm not sure; unfortunately we haven't had the time to look at this issue carefully (hence the lack of progress here). For what it's worth, I did take a stab at a solution for this issue early on, and it required a fair bit of time investment for me to feel confident it's correct, but the solution I drafted was much more complicated than this. It's possible I've missed something, but at the moment I don't feel the solution is likely to be this simple.
New tests would need to be part of any solution, yes. I don't think we test all the edge cases currently. You'll want to do that exhaustively to convince yourself (and us/others) that the patch is correct. |
Describe the issue
I have a test which uses EXPECT_NONFATAL_FAILURE.
I've recently started using --gtest_repeat (which is fantastic) and want to use --gtest_break_on_failure for my debugger to track down a rare timing issue.
It seems that break_on_failure is not checking that we are inside an EXPECT_NONFATAL_FAILURE clause and breaking execution.
Steps to reproduce the problem
See example at https://godbolt.org/z/rETraz1Pv
Remove the --gtest_break_on_failure command-line argument and the test will now pass
What version of GoogleTest are you using?
1.10.0 (Sorry, this is all that is built in to godbolt, I don't have a fast way to test with a newer version)
What operating system and version are you using?
godbolt (linux)
What compiler and version are you using?
GCC 10.4 x86
What build system are you using?
godbolt
Additional context
No response
The text was updated successfully, but these errors were encountered: