Bugzilla – Bug 1692
TestCase::changing number of UE's in test case constructor causes test suite to be not found
Last modified: 2013-06-13 18:51:26 EDT
Created attachment 1605 [details] patch that allows to reproduce the bug using ns-3-dev changeset 991d435b115f configured with --enable-tests --enable-examples --enable-modules=lte I do this, and I get the expected results: ./test.py -s lte-rrc [snip] PASS: TestSuite lte-rrc 1 of 1 tests passed (1 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors) Note that the test lte-rrc has defined several test cases with fullness QUICK and EXTENSIVE. There are also some test cases with TAKES_FOREVER, but they are commented out. Now, if I try to uncomment one of the TAKES_FOREVER test cases (see attached patch), I get this buggy behavior: ./test.py -s lte-rrc [snip] The test suite was not run because an unknown test suite name was requested. same with other fullness levels: $ ./test.py -s lte-rrc -f TAKES_FOREVER [snip] The test suite was not run because an unknown test suite name was requested. $ ./test.py -s lte-rrc -f EXTENSIVE [snip] The test suite was not run because an unknown test suite name was requested. The expected behavior is that test.py finds the test suite and runs the test cases with the specified fullness.
It looks like the bug appears even when you leave the test duration alone and only change the first argument for the test case constructor, LteRrcConnectionEstablishmentTestCase(), which has the following specification: /** * * * \param nUes number of UEs in the test * \param tc connection time base value for all UEs in ms * \param tConnIncrPerUe additional connection time increment for each UE index (0...nUes-1) in ms * \param delayDiscStart expected duration to perform connection establishment in ms * */ LteRrcConnectionEstablishmentTestCase ( uint32_t nUes, uint32_t nBearers, uint32_t tc, uint32_t tConnIncrPerUe, uint32_t delayDiscStart, bool useIdealRrc, bool admitRrcConnectionRequest); These work with nUes = 3 and 50: AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 3, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 50, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); These don't work with nUes = 51, 55, 60, 99, and 100: AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 51, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 55, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 60, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 99, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 100, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); It, therefore, definitely looks like the problem is related to the number of UEs in the test.
Commenting out this line makes the test suite be runnable: diff -r 0ac59a7893de src/lte/test/test-lte-rrc.cc --- a/src/lte/test/test-lte-rrc.cc Sun Jun 02 09:27:51 2013 -0700 +++ b/src/lte/test/test-lte-rrc.cc Wed Jun 12 10:53:36 2013 -0700 @@ -112,7 +112,7 @@ } else { - NS_ASSERT (nUes <= 50); + //NS_ASSERT (nUes <= 50); nRaAttempts += 10; } for nUes = 51: AddTestCase (new LteRrcConnectionEstablishmentTestCase ( 51, 0, 10, 0, 1, useIdealRrc, true), TestCase::EXTENSIVE); But, that is probably not what you would want to do in this code, Nicola. So, I will let you decide what to do for this test suite.
Thanks Mitch for spotting the issue. I'll take care of fixing the lte-rrc test. Still, I find that the output of test.py "The test suite was not run because an unknown test suite name was requested." is misleading. It should instead report that the test suite crashed.
(In reply to comment #3) > Thanks Mitch for spotting the issue. I'll take care of fixing the lte-rrc test. > > Still, I find that the output of test.py > > "The test suite was not run because an unknown test suite name was requested." > > is misleading. It should instead report that the test suite crashed. That line in the code knocks out all of the test suites. If you run test.py, only examples will be executed, no test suites. So, the test suite doesn't crash because there are no test suites to run. I'm not sure why that happens, but might be due to the macro that was used.
I replaced this: NS_ASSERT (nUes <= 50); with this, which got rid of the macro: assert(nUes <= 50); and it still removed all of the test suites. I don't have a good sense how to debug this.