Zephyr: tests/posix/common failed on multiple ARM platforms.

[chen-png]

Describe the bug
This test tests/posix/common failed on reel_board, frdm_k64f, mimxrt1050_evk and sam_e70_xplained boards.

To Reproduce
Steps to reproduce the behavior:

1. west build -b reel_board -p auto tests/posix/common/ -DCONFIG_NEWLIB_LIBC=n
2. west flash
3. See error

Screenshots or console output
* Booting Zephyr OS build zephyr-v2.2.0-347-gcd90d49a8627 *
Running test suite posix_apis

starting test - test_posix_pthread_execution

**Assertion failed at ZEPHYR_BASE/tests/posix/common/src/pthread.c:294: test_posix_pthread_execution: (ret not equal to ESRCH)**

uninitialized getname!
FAIL - test_posix_pthread_execution

starting test - test_posix_pthread_termination
Thread 0 starting with a priority of 4
Cancelling thread 0
Thread 1 starting with a priority of 3
Cancelling thread 1
Thread 1 could not be cancelled
Thread 2 starting with a priority of 2
Cancelling thread 2
Thread 3 starting with a priority of 1
Cancelling thread 3
Thread 3 could not be cancelled
PASS - test_posix_pthread_termination

starting test - test_posix_multiple_threads_single_key

Different threads set different values to same key:
thread 0: set value = 536876524 and retrieved value = 536876524
thread 1: set value = 536876780 and retrieved value = 536876780

PASS - test_posix_multiple_threads_single_key
......
starting test - test_posix_rw_lock

main acquire WR lock and 3 threads acquire RD lock
Thread 2 scheduling policy = 1 & priority 3 started
Not able to get RD lock on trying, try again
Thread 1 scheduling policy = 1 & priority 2 started
Not able to get RD lock on trying, try again
Thread 0 scheduling policy = 1 & priority 1 started
Not able to get RD lock on trying, try again
Parent thread releasing WR lock
Thread 2 got RD lock
Thread 1 got RD lock
Thread 0 got RD lock
Thread 1 releasing RD lock
Thread 1 acquiring WR lock
Thread 0 releasing RD lock
Thread 0 acquiring WR lock
Thread 2 releasing RD lock
Thread 2 acquiring WR lock
Thread 1 acquired WR lock
Parent thread acquiring WR lock again
Thread 1 releasing WR lock
Parent thread acquired WR lock again
Parent thread releasing WR lock again

3 threads acquire WR lock
Main thread acquiring RD lock
Thread 2 acquired WR lock
Thread 2 releasing WR lock
Main thread acquired RD lock
Main thread releasing RD lock
Thread 0 acquired WR lock
Thread 0 releasing WR lock
PASS - test_posix_rw_loc

Test suite posix_apis failed.

PROJECT EXECUTION FAILED

Environment (please complete the following information):

• OS: fedora 28
• Toolchain: zephyr-sdk-0.11.1
• Commit ID: cd90d49a8627

[ioannisg]

I bisected, tried the test on nrf52840_pca10056, and the offending commit seems to be the following:
https://github.com/zephyrproject-rtos/zephyr/commit/17b19eb810e2429bf91fb231bbeae4a3c82bf0dc

merged in PR #22845 .

The error I see is:

starting test - test_posix_pthread_execution

    Assertion failed at ../src/pthread.c:294: test_posix_pthread_execution: (ret not equal to ESRCH)
uninitialized getname!
FAIL - test_posix_pthread_execution

@chen-png can you confirm my finding?

Copying @nslowell (author of #22845) and reviewers/maintainers/release-team-members: @pfalcon @andrewboie @jhedberg

[nslowell]

@ioannisg Would you mind assisting with some debugging? QEMU didn't show any issues. Is the memory space of newthread[0] somehow non-zero at the point of failure?

[chen-png]

@ioannisg yes, this issue happened since 17b19eb.

[ioannisg]

@ioannisg Would you mind assisting with some debugging? QEMU didn't show any issues. Is the memory space of newthread[0] somehow non-zero at the point of failure?

Will take a look and update here.

[chen-png]

this test also failed on iotdk board.

[pfalcon]

Is the memory space of newthread[0] somehow non-zero at the point of failure?

That's exactly what happens here - use of uninitialized value. The matter is aggravated by using confusing variable names in the testcases. I'm about to submit patch.

[pfalcon]

Fix posted: https://github.com/zephyrproject-rtos/zephyr/pull/23556 . (I would humbly suggest it as an example of a good commit message, which explains the issue, what complicated investigating the issue, and different strategies for addressing both, and why particular solutions were chosen.)