Hi,
building osmo-pcu on a raspberry Pi 3, I noticed a failure in make check:
## --------------------------------- ## ## osmo-pcu 0.2.896-0a8f test suite. ## ## --------------------------------- ##
Regression tests
1: rlcmac ok 2: ts_alloc ok 3: tbf ok 4: bitcomp FAILED (testsuite.at:30) 5: edge ok 6: types ok 7: ms ok 8: llc ok 9: llist ok 10: codel ok 11: fn ok
## ------------- ## ## Test results. ## ## ------------- ##
ERROR: All 11 tests were run, 1 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ##
The exact same test also fails on a raspberry Pi 2, with the same osmo-pcu and gcc versions but succeeds on an old Pentium4
Feel free to contact me if you need further informations.
----- Arnaud ZANETTI
On Fri, Mar 24, 2017 at 10:53:53AM +0100, Arnaud ZANETTI wrote:
4: bitcomp FAILED (testsuite.at:30)
- testsuite.at:26: testing bitcomp ...
./testsuite.at:30: $OSMO_QEMU $abs_top_builddir/tests/bitcomp/BitcompTest --- experr 2017-03-24 10:43:11.086019127 +0100 +++ /home/pi/Src/osmo/src/osmo-pcu/tests/testsuite.dir/at-groups/4/stderr 2017-03-24 10:43:11.096019097 +0100 @@ -11,9 +11,9 @@ Run_length = 19 Run_length = 32
-expected data = ff ff ff f8 00 00 01 ff ff ff f8 00 00 00 ff ff ff fe 00 00 3f ff ff ff db +expected data = ff ff ff f8 00 00 01 ff ff ff f8 00 00 00 ff ff ff fe 00 00 3f ff ff ff c0 expected len = 194 -decoded data = ff ff ff f8 00 00 01 ff ff ff f8 00 00 00 ff ff ff fe 00 00 3f ff ff ff db +decoded data = ff ff ff f8 00 00 01 ff ff ff f8 00 00 00 ff ff ff fe 00 00 3f ff ff ff c0 decoded len = 194
Arnaud, many thanks for submitting your report!
I took a look, and it actually is an amazingly stupid bug in the test itself. In fact 0xc0 is the correct expected result, which our decoding routines also actually return, but the author of the test has put two osmo_hexdump() calls into the same log line. Since osmo_hexdump() uses an internal static buffer, that can't work: one of the two hexdumps wins, so that both dumped strings are the same. m(
On our "usual" systems, the expected hexdump wins and it prints them both as the expected value. On the pi, the actually decoded hexdump wins, and it prints both "expected" and "decoded" data as what the decoding routine returns.
In other words, the test never before printed expected vs. decoded results, and the author has never properly checked the stdout / stderr results. The test does check expected results, but not the remaining bits after the decoded data.
In my/our review, we oversaw the double osmo_hexdump() and a bunch of other issues. Looking into this triggered a whole series of fixes, more explanations in the commit logs: https://gerrit.osmocom.org/#/q/topic:bitcomp_test
The last one also uncovers a test marked "invalid" which seems to be valid, or fails to be detected as invalid. I don't have a fix for that, would be good if someone else could look into that.
~N
osmocom-net-gprs@lists.osmocom.org
-
Arnaud ZANETTI -
Neels Hofmeyr