-
Notifications
You must be signed in to change notification settings - Fork 9
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
990 - Non-MPI tests run without MPI #998
Conversation
set_tests_properties( | ||
${${CUR_TEST_LIST}} | ||
PROPERTIES TIMEOUT 60 | ||
FAIL_REGULAR_EXPRESSION "FAILED;should be deleted but never is;Segmentation fault" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I always wonder about that line..
Codecov Report
@@ Coverage Diff @@
## develop #998 +/- ##
===========================================
- Coverage 77.43% 77.41% -0.03%
===========================================
Files 660 656 -4
Lines 25204 25130 -74
===========================================
- Hits 19517 19454 -63
+ Misses 5687 5676 -11
|
62d2dcb
to
9dedbdd
Compare
I have switched
sample stacktrace: Program received signal SIGSEGV, Segmentation fault.
0x0000555555fea37c in vt::theConfig () at ../src/vt/runtime/runtime_get.cc:136
136 vt::arguments::AppConfig* theConfig() { return &CUR_RT->theArgConfig->config_; }
(gdb) bt
#0 0x0000555555fea37c in vt::theConfig () at ../src/vt/runtime/runtime_get.cc:136
#1 0x0000555555f97407 in vt::tests::unit::TestLBReader_test_lb_read_1_Test::TestBody (this=0x555556a97d50) at ../tests/unit/lb/test_lb_reader.cc:98
#2 0x0000555555fd633b in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void> (object=0x555556a97d50, method=&virtual testing::Test::TestBody(),
location=0x555556660ff3 "the test body") at ../tests/extern/googletest/googletest/src/gtest.cc:2433
#3 0x0000555555fcee51 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x555556a97d50, method=&virtual testing::Test::TestBody(),
location=0x555556660ff3 "the test body") at ../tests/extern/googletest/googletest/src/gtest.cc:2469
#4 0x0000555555fa9c8c in testing::Test::Run (this=0x555556a97d50) at ../tests/extern/googletest/googletest/src/gtest.cc:2508
#5 0x0000555555faa677 in testing::TestInfo::Run (this=0x555556a85fa0) at ../tests/extern/googletest/googletest/src/gtest.cc:2684
#6 0x0000555555faadb2 in testing::TestSuite::Run (this=0x555556a86430) at ../tests/extern/googletest/googletest/src/gtest.cc:2816
#7 0x0000555555fb6e6e in testing::internal::UnitTestImpl::RunAllTests (this=0x555556a860f0) at ../tests/extern/googletest/googletest/src/gtest.cc:5338
#8 0x0000555555fd7864 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x555556a860f0,
method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x555555fb6a66 <testing::internal::UnitTestImpl::RunAllTests()>,
location=0x555556661a30 "auxiliary test code (environments or event listeners)") at ../tests/extern/googletest/googletest/src/gtest.cc:2433
#9 0x0000555555fd008f in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x555556a860f0,
method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x555555fb6a66 <testing::internal::UnitTestImpl::RunAllTests()>,
location=0x555556661a30 "auxiliary test code (environments or event listeners)") at ../tests/extern/googletest/googletest/src/gtest.cc:2469
#10 0x0000555555fb56ae in testing::UnitTest::Run (this=0x555556a70e40 <testing::UnitTest::GetInstance()::instance>) at ../tests/extern/googletest/googletest/src/gtest.cc:4925
#11 0x0000555555f77623 in RUN_ALL_TESTS () at ../tests/extern/googletest/googletest/include/gtest/gtest.h:2473
#12 0x0000555555f76967 in main (argc=1, argv=0x7fffffffda98) at ../tests/unit/main.cc:70 |
@pnstickne I have run them locally a couple of times and they fail quite regularly because of some file reading problems:
I think this could be extracted into a separate issue with 2 goals:
|
Removing the dependencies is the 'proper' method. This test has never a reason to be run in parallel or MPI. Thee was not usages of |
08d6616
to
633cfe8
Compare
The debug_ support now uses a Also update the LB reading to have no external theConfig dependency. |
6b65305
to
565be76
Compare
} | ||
} /* end namespace vt */ | ||
|
||
namespace vt { namespace debug { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only meant to be used from the debug/diagnostic code, hence the vt::debug
namespace. This also aligns with vt::debug::preNode
. Only single access is exposed, freeing singular-use case sites of logic.
} | ||
|
||
} /* end namespace runtime */ | ||
|
||
#undef CUR_RT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not relevant to undef in .cc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the builds look fine and the PR looks good overall, only minor comments to address
- Tests that use TestHarness (as opposed to TestParallelHarness) should be in files with a '.nompi' somewhere in their extension. These tests will be invoked as direct executables without going through mpirun (and thus should not invoke an MPI calls). separate out .nompi tests in cmake cmake;
- Move some exist tests over to such.
- The spec API has changed slightly to increase encapsulation. The 'openSpec(filename)' call now replaces disparate calls to read/check the specification and avoid any internal assumptions about which file is read.
- The preConfig method is like the preNode method. It is SAFE to use without a run-time, freeing any debug print from being explicitly tied to the RT. (However, the defaults are 'flags off', so debugging is effectively entirely disabled until the VT init process starts.)
- Small changes for clarity.
545586f
to
83b1f75
Compare
Here is an overview of what got changed by this pull request: Clones added
============
- tests/unit/lb/test_lb_reader.nompi.cc 2
See the complete overview on Codacy |
Tests that use the TestHarness (not the ParallelTestHarness) don't / shouldn't need or use MPI.
When run under MPI, multiple processes are still spawned which can result in unexpected conflicts that can't be gated via rank because.. well, there is no rank.
As a side-effect of these "nompi" tests only running once, there is a slight reduction of test executions overall.
The "nompi" tests implicitly guarantee that they can't use MPI (as they will fail if an attempt is made). The reverse is no true, although it's largely inconsequential to spin up VT/MPI in the ParallelTestHarness and then not use it.