#293 [Qpccp 6.9.2] test of assertion fail now

[Anonymous]

Hello.
We just updated to QP 6.9.2 and one of our test on our target now fail.
I'm not an expert of qutest yet.

the test fail when we try to test and assertion.

here is the actual test: (q_assert_file_path is a variable with the file name, that's not the issue).

test("GetBitAndAdvance: output SHOULD be assert error WHEN GetBitAndAdvance() is called after constructing the bit " \
     "iterator object with the default constructor")
command(2, 0)
expect(f"@timestamp =ASSERT= Mod={q_assert_file_path},Loc=200")

the Qspy output with QP 6.9.1 that works.

           Trg-Ack  QS_RX_TEST_SETUP
           Trg-Ack  QS_RX_COMMAND
0000000001 =ASSERT= Mod=../src/utils/BitIterator.cpp,Loc=200
           Trg-Ack  QS_RX_TEST_TEARDOWN

and the output with 6.9.2 that does not work.

I also create an issue on github (don't know which is the correct way to report)
https://github.com/QuantumLeaps/qpcpp/issues/10

           Trg-Ack  QS_RX_TEST_SETUP
           Trg-Ack  QS_RX_COMMAND
0000000001 =ASSERT= Mod=../src/utils/BitIterator.cpp,Loc=200
           Trg-ERR  QS_RX_INFO
           Trg-ERR  0x50
           Trg-Ack  QS_RX_TEST_TEARDOWN

is the 2 lines "Trg-ERR" expected with 6.9.2? or did I miss something during the upgrade?

[Quantum Leaps]

Hi Stéphane,
I can't reproduce any problems with testing assertions, including failing assertions, in QP/C/C++ 6.9.2. For example, here is output from a failing assertion test:

           Trg-Ack  QS_RX_TEST_SETUP
0000000001 FIXTURE_SETUP
           Trg-Ack  QS_RX_COMMAND
0000000002 =ASSERT= Mod=test_qutest,Loc=100
           Trg-Ack  QS_RX_TEST_TEARDOWN
0000000003 FIXTURE_TEARDOWN
   <COMMS> TCP-IP   Disconn from Host=127.0.0.1,Port=54230
----------------------------------------------------------
   <F-END> Detached ######################################

I would highly recommend that you run this simple test on your system as well. I attach two files (test_assert.py and test_qutest.cpp) that you need to copy to the directory qpcpp/examples/qutest/self_test/test. After you've done this, simply build and run the test on your host by typing make. Please post back to this thread how it went.

--MMS

P.S. The error Trg-ERR 0x50 is reported when the target discovers a "bad frame", meaning that the target received some broken packet. As I said, I cannot reproduce it with the simple tests.

[Anonymous]

Thanks I will do the test.
Just to say..
The same test (our test) works when I do it on local (PC host) but not when I do it on the nucleo 64 STM32G474RE board. with RS232 connection for Qspy.
we do the test when we can on both.. on local host and on target.. with different make file etc.

the test was working fine on both with V6.9.1 but fail on the nucleo board with 6.9.2

[Quantum Leaps]

Oh, that's interesting point.

The failure on embedded target would suggest some problem with correct resetting your STM32 CPU. Specifically, assertion failure should cause the QUTest to send the reset command to the target. It seems that your target might not be resetting correctly.

Could you you please check the implementation of the void QS::onReset() callback for your STM32 board? Typically, for ARM Cortex-M CPUs this callback should invoke NVIC_SystemReset();.

--MMS

[Anonymous]

ooops.. forgot to say.. that all tests pass.. just the assertion fail.

[Quantum Leaps]

OK, I was able to reproduce the problem on an embedded board. I'll look into this and post to this thread when I find out more...
--MMS

[Anonymous]

Thanks for your investigation, if you need I do other test or anything else, just let me know.
Best regards.
Stéphane

[Quantum Leaps]

The problem has been found and the fix is available on GitHub:

• QP/C https://github.com/QuantumLeaps/qpc
• QP/C++ https://github.com/QuantumLeaps/qpcpp

The problem was a too aggressive optimization in QS::rxParse(). The "tail" pointer of the RX-buffer was not updated until the end of the function. In case of assertion, the end was not reached and the QS::rxParse() was called again. The already processed bytes were processed again.

Anyway, the fix should be working now. Please check.

--MMS

[Anonymous]

I confirm the fix solve my issue,

Thanks for the quick fix.
Best regards
Stéphane

[Quantum Leaps]

Fixed in QP/C/C++ 6.9.3.
--MMS