xtimer: valgrind complains about uninitialized variables for jumps

[miri64]

Running tests/xtimer_msg_receive_timeout in valgrind yields the following result:

main(): This is RIOT! (Version: 2015.12-devel-718-gc143-beutlin-pkg/port/lwip)
==7035== Conditional jump or move depends on uninitialised value(s)
==7035==    at 0x804BF92: _is_set (sys/xtimer/xtimer_core.c:53)
==7035==    by 0x804C398: xtimer_remove (sys/xtimer/xtimer_core.c:244)
==7035==    by 0x804C114: xtimer_set (sys/xtimer/xtimer_core.c:122)
==7035==    by 0x804BCB6: xtimer_set_msg (sys/xtimer/xtimer.c:124)
==7035==    by 0x804B99D: main (tests/xtimer_msg_receive_timeout/main.c:34)
==7035==  Uninitialised value was created by a stack allocation
==7035==    at 0x804B949: main (tests/xtimer_msg_receive_timeout/main.c:27)
==7035== 
==7035== Conditional jump or move depends on uninitialised value(s)
==7035==    at 0x804BF9C: _is_set (sys/xtimer/xtimer_core.c:53)
==7035==    by 0x804C398: xtimer_remove (sys/xtimer/xtimer_core.c:244)
==7035==    by 0x804C114: xtimer_set (sys/xtimer/xtimer_core.c:122)
==7035==    by 0x804BCB6: xtimer_set_msg (sys/xtimer/xtimer.c:124)
==7035==    by 0x804B99D: main (tests/xtimer_msg_receive_timeout/main.c:34)
==7035==  Uninitialised value was created by a stack allocation
==7035==    at 0x804B949: main (tests/xtimer_msg_receive_timeout/main.c:27)
==7035== 
Message received: 44
Timeout!
Message received: 44
Timeout!

This is due to target and/or long_target being checked early on an xtimer_remove() in xtimer_set() and the xtimer not being used yet. It works for now because the timer is set in the BSS section, which results in the timer always being 0 in the beginning, but it might lead to unwanted behavior.

[OlegHahm]

I thought I fixed that in #3902

[miri64]

I'll check again, if I maybe have used an old version of master.

[OlegHahm]

I also haven't looked if I missed something in #3902, so it might be that it still may be uninitialized.

[miri64]

nope, still an issue in current master.

[miri64]

(562218d)

[miri64]

Mh, may it be that #4272 reverted that for xtimer_msg_receive_timeout()?

[miri64]

Ah, the problem is not xtimer_msg_receive_timeout() but xtimer_msg_set[64](). #3902 doesn't offer a solution for that.

[kaspar030]

That uninitialized check might cause an iteration through active timers, but an't lad to corruption or a crash. Therefore I'd like to postpone it for after the release.

[miri64]

Maybe the fix isn't so much a code, but a documentation problem ;-). If you use xtrimer_msg_set() you need to initialize those two values.

[haukepetersen]

@kaspar030, @authmillenon: should we postpone this again?

[miri64]

Provided fix in #5216