RIOT-OS/RIOT
RIOT-OS/RIOT
1
0
Fork 0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
Code Releases Activity
c47bd3d402
RIOT/tests/thread_msg_block_w_queue
History
chrysn 87847b1de4 tests: Fix thread return with local message queue 
When a message queue is configured from the stack, that main function
must never return -- otherwise, during sched_task_exit (which the
thread's function "returns" to), message senders might still send
messages into already freed stack space (which would be reused by
sched_task_exit).

Co-authored-by: Marian Buschsieweke <maribu@users.noreply.github.com>
2022-01-11 21:51:09 +01:00
..
tests tests: move testrunner import up 2018-08-13 14:11:24 +02:00
main.c tests: Fix thread return with local message queue 2022-01-11 21:51:09 +01:00
Makefile tests: remove uneeded DISABLE_MODULE+=auto_init 2020-02-12 16:51:34 +01:00
Makefile.ci boards: introduce atmega328p-xplained-mini 2021-03-27 14:10:19 -03:00
README.md tests/thread_msg_block_w_queue: add README & pexpect script, extend comments 2017-03-07 09:04:56 -08:00

README.md

Background

This test application checks for the behavior reported in https://github.com/RIOT-OS/RIOT/issues/100:

Usually, when a thread (here sender_thread) sends a message to another thread (here the main thread) whose message queue already holds a message, the message of sender_thread is copied into main's message queue and sender_thread is set to STATUS_PENDING. However, this should not happen if sender_thread is currently in STATUS_REPLY_BLOCKED mode, since it is in the middle of a different, blocking send.

In the aforementioned issue, it was reported that this undesired behavior was happening. It has been fixed since, and this test ensures that it doesn't re-occur again.

Expected result

The output should look as follows:

sender_thread start
main thread alive

If you see

ERROR: sender_thread should be blocking

something went wrong.