-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/posix/common failed on multiple ARM platforms. #23473
Comments
I bisected, tried the test on nrf52840_pca10056, and the offending commit seems to be the following: merged in PR #22845 . The error I see is:
@chen-png can you confirm my finding? Copying @nslowell (author of #22845) and reviewers/maintainers/release-team-members: @pfalcon @andrewboie @jhedberg |
@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. |
this test also failed on iotdk board. |
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. |
Recently added test for pthread_getname_np()/pthread_setname_np() functions used uninitialized array value. As we can't check behavior for arbitrary uninitialized value, but at most NULL value, make the test calls to explicitly use NULL, to make the test intent clear (instead of for example initializing the original array with zeros). Also, these test cases use variable names not consistent with Zephyr codestyle, and named to generically to cause confuse when used in a general context of the test_posix_pthread_execution() function, so rename them to be specific. (And alternative would be to separate pthread_getname_np()/pthread_setname_np() tests into a separate function, but it was indeed practical to piggyback them on existing test_posix_pthread_execution()). Fixes: zephyrproject-rtos#23473 Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Fix posted: #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.) |
Recently added test for pthread_getname_np()/pthread_setname_np() functions used uninitialized array value. As we can't check behavior for arbitrary uninitialized value, but at most NULL value, make the test calls to explicitly use NULL, to make the test intent clear (instead of for example initializing the original array with zeros). Also, these test cases use variable names not consistent with Zephyr codestyle, and named to generically to cause confuse when used in a general context of the test_posix_pthread_execution() function, so rename them to be specific. (And alternative would be to separate pthread_getname_np()/pthread_setname_np() tests into a separate function, but it was indeed practical to piggyback them on existing test_posix_pthread_execution()). Fixes: #23473 Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Recently added test for pthread_getname_np()/pthread_setname_np() functions used uninitialized array value. As we can't check behavior for arbitrary uninitialized value, but at most NULL value, make the test calls to explicitly use NULL, to make the test intent clear (instead of for example initializing the original array with zeros). Also, these test cases use variable names not consistent with Zephyr codestyle, and named to generically to cause confuse when used in a general context of the test_posix_pthread_execution() function, so rename them to be specific. (And alternative would be to separate pthread_getname_np()/pthread_setname_np() tests into a separate function, but it was indeed practical to piggyback them on existing test_posix_pthread_execution()). Fixes: zephyrproject-rtos#23473 Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
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:
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
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):
The text was updated successfully, but these errors were encountered: