Release 2015.12 - RC3

[cgundogan]

Status of all tests for the Release Candidate 3 of the 2015.12 release.

Please check off all tests that performed successfully. Inline any errors/warnings you encounter in this list.
The names I assigned are tentative. Feel free to re-assign or execute tests that are not marked with your name.

• 01-CI @cgundogan @thomaseichinger (OS X)
  • Task 01
    • tests nhdp, fault_handler, cpp11-* and example ccn-lite-relay do not build with clang make: clang is more pedantic than gcc RIOT#4560 cpp11: clang doesn't allow mutex_t to be used with constexpr RIOT#4583
  • Task 02
    • tests-relic does not build with clang pkg: building relic with clang fails RIOT#4590
  • Task 03
    • fib_tests.test_fib_01_fill_unique_entries (tests/unittests/tests-fib/tests-fib.c 89) exp 20 was 2
    • fib_sr_tests.test_fib_sr_06_create_sr_with_hops (tests/unittests/tests-fib_sr/tests-fib_sr.c 327) exp 0 was -2
  • Task 04
• 02-Tests @A-Paul @thomaseichinger (OS X) (see 02-tests Release 2015.12 - RC3 #14 for details)
  • Task 01
    • texts/libfixmath some errors, see dump at Release 2015.12 - RC3 #12 (comment)
    • tests\xtimer_hang results in an access violation on make term
  • Task 02
  • Task 03
• 03-Single Hop IPv6 ICMP @PeterKietzmann
  • Task 01
  • Task 02
  • Task 03
• 04-Single Hop 6LoWPAN ICMP @authmillenon
  • Task 01
  • Task 02
  • Task 03
  • Task 04
• 05-Single Hop Route @authmillenon
  • Task 01
  • Task 02
    • not working with default routes but mapping to link-local address (probably related to FIB: default route not found in FIB RIOT#4543)
  • Task 03
• 06-Single Hop UDP @haukepetersen
• 07-Multi Hop @cgundogan
  • Task 01
    • needs shell fib: recognize the default route as net prefix (backport of #4584) RIOT#4594
  • Task 02
    • needs shell fib: recognize the default route as net prefix (backport of #4584) RIOT#4594
  • Task 03
  • Task 04
• 08-Interop @OlegHahm
  • Task 01
  • Task 02
  • Task 03
  • Task 04
  • Task 05

[miri64]

@cgundogan was asking me to run make -C tests/unittests tests-fib test to verify his findings that fib_tests.test_fib_01_fill_unique_entries is failing. This is the case. A quick bisect revealed that 42d387a42 so there seems to be a timing related issue in the fib (see also RIOT-OS/RIOT#4513)

[cgundogan]

Thanks for the hint @authmillenon. I digged deeper into this issue and encountered a possible bug in xtimer ( @kaspar030 ). After several micro seconds (~200-600) xtimer_now64 starts to overflow. Due to this overflow the fib purges all routes, because it assumes that the lifetime timed out. We need to address this issue within the fib (preferably not within the current release), because it effectivly has to deal with timer overflows anyhow.

As for xtimer: @kaspar030 : xtimer calls _next_period() within _timer_callback after 200-600 microseconds. I assume this is not a wanted behaviour, is it? Do you have any hints what might be wrong here?

EDIT: I debugged while running the unittests (embunit), maybe it's relevant..
EDIT2: tests were executed on native

[cgundogan]

To reproduce: run make tests-fib test. The first test will fail because of the above issue. At a certain point, all routes will be purged because of the mentioned overflow and the rest of the routes will be inserted at the beginning of the table => the amount of routes within the table does not equal the expected amount, hence the test fails

[BytesGalore]

@cgundogan regarding fib_tests.test_fib_01_fill_unique_entries: as you said the wrong value returned by xtimer_now64() here [1]:

if (table->data.entries[i].lifetime < now)
...
table->data.entries[3].lifetime: 10000095, now: 4294967545
table->data.entries[4].lifetime: 10000102, now: 4294967545
table->data.entries[5].lifetime: 10000111, now: 4294967545
...

This results in auto-invalidate the entry.
I guess its the same problem with RIOT-OS/RIOT#4513.

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/network_layer/fib/fib.c#L83

[BytesGalore]

Not really a test [1], but it produces the xtimer hickup on native.

[1] https://github.com/BytesGalore/RIOT/tree/test_xtimer_native

[kaspar030]

@cgundogan @BytesGalore This is on native, right? Somehow, xtimer_now() starts very close to 2^32, so it overflows early. Still, xtimer_now() should be growing. Are the lifetimes initialized relative to xtimer_now()?

edit I mean xtimer_now64(), as xtimer_now() will overflow, too.

[kaspar030]

Ok, I see the bug. Will open an issue.

[BytesGalore]

Are the lifetimes initialized relative to xtimer_now()?

yes, e.g. table->data.entries[3].lifetime: 10000095 stems from 10s + xtimer_now()

[BytesGalore]

and yes its on native

[kaspar030]

@BytesGalore @cgundogan Could you check out RIOT-OS/RIOT#4585?

[BytesGalore]

@kaspar030 I just let RIOT-OS/RIOT#4585 run with my "test" [1] and the overflow seems not to occur anymore :D

[1] https://github.com/BytesGalore/RIOT/tree/test_xtimer_native

[A-Paul]

Output for tests/libfixmath (haven't tested in RC1 because main.c in not @ingroup tests)

paul@hedon:/usr/local/src/RIOT/tests/libfixmath$ make term|./do-test.py
Calculation: abs result != exp result, abs error > limit
Unary.
exp(8.5000): 4914.7688 != 4914.7354, 0.0334 > 0.011
exp(8.7500): 6310.6881 != 6310.7139, 0.0258 > 0.011
exp(9.5000): 13359.7268 != 13359.7076, 0.0192 > 0.011
exp(9.7500): 17154.2288 != 17154.1737, 0.0551 > 0.011
tan(-1.5708): 272241.8084 != 32768.0000, 239473.8084 > 0.011
tan(1.1794): 2.4231 != 2.4076, 0.0155 > 0.011
tan(1.2294): 2.8145 != 2.7908, 0.0237 > 0.011
tan(1.2794): 3.3341 != 3.2967, 0.0374 > 0.011
tan(1.3294): 4.0618 != 3.9992, 0.0626 > 0.011
tan(1.3794): 5.1608 != 5.0458, 0.1150 > 0.011
tan(1.4294): 7.0251 != 6.7833, 0.2418 > 0.011
tan(1.4794): 10.9109 != 10.2516, 0.6593 > 0.011
tan(1.5294): 24.1429 != 20.7281, 3.4148 > 0.011
asin(-1.0000): -1.5708 != 0.0000, 1.5708 > 0.011
acos(-1.0000): 3.1416 != 1.5708, 1.5708 > 0.011
Binary.
Done.
17894 calculations passed.
15 calculations had errors.

Can't say if this is success or not. @Kijewski please give a judgement.

[miri64]

Best thing you can probably do is look-up who the author was, and ask them what the expected output should be.

[miri64]

There is a test script in there btw (written by @Kijewski) but it does not seem to work.

[A-Paul]

There is a test script in there btw (written by @Kijewski) but it does not seem to work.

@authmillenon, look at the command line of my output. Took me 1/2 hour to figure that shit out.

Happy new year btw. :D

[miri64]

Superseded by #16 (and happy new year to you too @A-Paul)