Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I7f9c56313cfaa74ebe666f44763a83d8102f5484
Related: OS#5034
search_runlen() must know the exact size in bits when parsing
the bits otherwise it read over the buffer.
Fixes testcase #7 which was wrongly decoded.
Change-Id: Ie34a0651e7e7efea4e9ecff1e3a467588113cf47
There is a duality of initialization: early_init() in bts.cpp wants to init
logging even before static instances get initialized. Make sure that
tall_pcu_ctx is initialized during early_init() as well. There is a build
context that does not seem to include bts.cpp (osmo-pcu-remote), so to be sure,
init tall_pcu_ctx as NULL and both in early_init() as well as pcu_main.cpp,
init both tall_pcu_ctx and logging if it is still NULL.
Change-Id: I2199b62d0270bd35dec2283e8f5b364b7c63915b
There's no need for each test case to carry their own log_info and
filter function. They can simply use the global gprs_log_info and
configure the stderr log verbosity according to their needs.
Change-Id: I8706a624e5d06e062d1198711aa197fbd0860769
The 'verify' flag is useless, we always want to verify everything. Replace
'verify' with 'expect_rc', expecting a specific decoding result per test set.
When an error code was returned, cut short the loop and skip printing expected
vs. decoded bits.
This uncovers the fact that the first test marked as "invalid inputs" does not
seem to be invalid after all, or at least does not produce an error to be
returned. For now, only uncover this fact, the fix shall be submitted later.
Change-Id: Icf815a8f1acb0e275463408450171df046879847
Before this, the expected data had seemingly random bits set after the end of
the expected decoding result. Make the test expect these extra bits as zero,
matching with the buffer initialization to zero.
In result_matches(), compare the full length of bytes instead of masking the
bits after the end of the decoded data (which caused us to not catch the wrong
expectation until now).
This fixes the underlying issues found in
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-March/000876.html
[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
from: Arnaud ZANETTI
on: Fri Mar 24 09:53:53 UTC 2017
Change-Id: I2501208e2f8b4f709efbcadbd1057c086472c9e6
The test wants to write multiline results, so it should use printf instead of
the logging system.
Split logs to only one hexdump per printf(). One cannot use osmo_hexdump twice
in one printf(); before this, one of the two hexdumps won, both dumps would
show as the same. Very bad for a regression test!
This uncovers a discrepancy between expected and produced results, proving that
the expected stderr output was not capable of uncovering test failures. The
test's check_result() function *has* always verified the decoded data, but only
up to the last decoded bit. Our expected data contains seemingly random bits
after the end of the decoded bits, but check_result() never compares those,
hence we don't catch that error. The extra bits should definitely be zero,
because the destination buffer is pre-initialized to zero -- fixed in a
subsequent patch.
This should cosmetically fix the build failure found in:
http://lists.osmocom.org/pipermail/osmocom-net-gprs/2017-March/000876.html
[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
from: Arnaud ZANETTI
on: Fri Mar 24 09:53:53 UTC 2017
The real fix will follow.
Change-Id: I24fc32eb55baaf22f9c6fdda917bfb8395d02b1c
In order to understand what the bitcomp test is logging, cosmetically rearrange
the code:
- memset bits_data before assigning to destination bitvec.
- use macro CEIL_DIV_8 to clarify what (x+7)/8 does.
- rename check_result() to result_matches() and return a bool,
also constify result_matches() args and pass a bitvec reference instead of
copying the bitvec struct.
- rearrange logging lines to make readable what is going on there.
- drop unused 'init_flag'
There are obviously errors like double hexdumps per log line, multiple newlines
in a LOGP statement and so forth: these shall be fixed by subsequent patches.
Change-Id: Id0da9d9b67f4713d3a67e3532ed44b8cb1bd1d08
Implemented tree based algorithm to decode compressed bitmap in EPDAN
as described in section 9.1.10 of 3GPP 44.060.
This algorithm intends to improve the performance over existing method.
New Regression test is added under bitcomp directory.
Test case is added to validate decompressed result of the bitmap
Present in EPDAN.
Test is done for multiple bitmaps of varying length.
Invalid inputs are also part of the test vector.
Change-Id: Ieae1992ed4b02bb1e09eec2d3de1a030eabd16ce
Pau Espin
Alexander Couzens
Harald Welte
Neels Hofmeyr