Project

General

Profile

Bug #4420

llc unit test fails in ARM (raspberrypi4)

Added by pespin 8 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
02/26/2020
Due date:
% Done:

100%

Spec Reference:

Description

osmo-pcu master (55f06c3d77563d5817107247c422d3e66115c352).

  9: llc                                             FAILED (testsuite.at:63)
======================== ./osmo-pcu-0.8.0.67-55f0/_build/sub/tests/testsuite.dir/09/testsuite.log

#                             -*- compilation -*-
9. testsuite.at:59: testing llc ...
../../../tests/testsuite.at:63: $OSMO_QEMU $abs_top_builddir/tests/llc/LlcTest
--- experr      2020-02-26 17:37:43.429241836 +0000
+++ /build/osmo-pcu-0.8.0.67-55f0/_build/sub/tests/testsuite.dir/at-groups/9/stderr     2020-02-26 17:37:43.509239670 +0000
@@ -1,3 +1,4 @@
+../../../src/llc.cpp:215:29: runtime error: signed integer overflow: 1582738663 * 1000 cannot be represented in type 'long int'
 dequeued msg, length 11 (expected 11), data 4c 4c 43 20 6d 65 73 73 61 67 65
 dequeued msg, length 17 (expected 17), data 6f 74 68 65 72 20 4c 4c 43 20 6d 65 73 73 61 67 65
 dequeued msg, length 13 (expected 13), data 4c 4c 43 20 6d 65 73 73 61 67 65 20 31
9. testsuite.at:59: 9. llc (testsuite.at:59): FAILED (testsuite.at:63)

Affected line in code (gprs_llc_queue::dequeue()):

    lifetime = tv_result.tv_sec*1000 + tv_result.tv_usec/1000;

History

#1 Updated by pespin 8 months ago

  • Status changed from New to In Progress

I submitted following patch which fixes one of the issues:
https://gerrit.osmocom.org/c/osmo-pcu/+/17282 llc_queue::{dequeue,enqueue}() refactor

However, there's still a new one:

 dequeued msg, length 11 (expected 11), data 4c 4c 43 20 6d 65 73 73 61 67 65
 dequeued msg, length 17 (expected 17), data 6f 74 68 65 72 20 4c 4c 43 20 6d 65 73 73 61 67 65
+../../../src/llc.cpp:216:29: runtime error: signed integer overflow: -864197545 * 1000 cannot be represented in type 'long int'
 dequeued msg, length 13 (expected 13), data 4c 4c 43 20 6d 65 73 73 61 67 65 20 31
 dequeued msg, length 13 (expected 13), data 4c 4c 43 20 6d 65 73 73 61 67 65 20 32
 dequeued msg, length 3 (expected 3), data 2a 41 2a

Forget the negative number, that because it was running with the wrong attempt to fix it. Still it gives a big number which basically comes from test_llc_meta():

info1.recv_time.tv_sec = 123456777;
info2.recv_time.tv_sec = 987654321;

When substracting both in gprs_llc_queue::dequeue():

timersub(&tv_now, &meta_storage->recv_time, &tv_result);
lifetime = tv_result.tv_sec*1000 + tv_result.tv_usec/1000;

So the tv_now (987654321) is waaaay in the future regarding meta_storage->recv_time (123456777), so apparently it cannot be stored (864197544*1000) in "uint32_t lifetime;" which interestingly according to the runtime error seems to be a "long int" in raspberrypi4 architecture...

So we need to check whether it makes sense for 2 enqueues to happen so different in time and then a dequeue for the first one. It probably doesn't make sense and we should decrease the time between both.

also TODO: move osmo_gettimeofday and recv_time + expire_time of MetaInfo and llc_queue to use a Monotonic clock (osmo_clock_gettime) so avoid running into weird stuff (like going to the past).

#2 Updated by pespin 7 months ago

  • % Done changed from 0 to 70

runtime error fixed by:
https://gerrit.osmocom.org/c/osmo-pcu/+/17459 tests/llc: Change unrealistic time jump to avoid runtime error under ARM

#3 Updated by pespin 7 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 70 to 90

use monotonic clock everywhere submitted here:
https://gerrit.osmocom.org/c/osmo-pcu/+/17460 Use clock_gettime(CLOCK_MONOTONIC) and timespec everywhere

Once merged, ticket can be closed.

#4 Updated by pespin 7 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)