Skip to content

ARC: tests/cmsis_rtos_v2/portability.cmsis_rtos_v2 fails on nsim_em and nsim_sem #14640

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

Closed
andrewboie opened this issue Mar 18, 2019 · 6 comments
Assignees
Labels
area: ARC ARC Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@andrewboie
Copy link
Contributor

===================================================================
starting test - test_thread_apis

    Assertion failed at /home/apboie/projects/zephyr3/zephyr/tests/cmsis_rtos_v2/src/thread_apis.c:88: thread2: (osThreadGetStackSize(thread_array[i]) <= STACKSZ is false)
stack size allocated is not what is expected
FAIL - test_thread_apis
===================================================================
starting test - test_thread_apis_dynamic

    Assertion failed at /home/apboie/projects/zephyr3/zephyr/tests/cmsis_rtos_v2/src/thread_apis.c:134: thread_apis_common: (osThreadGetCount() not equal to 2)
Incorrect number of cmsis rtos v2 threads
FAIL - test_thread_apis_dynamic
===================================================================
starting test - test_thread_prio

    Assertion failed at /home/apboie/projects/zephyr3/zephyr/tests/cmsis_rtos_v2/src/thread_apis.c:63: thread1: *args->yield_check not equal to 2

FAIL - test_thread_prio
===================================================================
starting test - test_thread_prio_dynamic

    Assertion failed at /home/apboie/projects/zephyr3/zephyr/tests/cmsis_rtos_v2/src/thread_apis.c:50: thread1: (strcmp(args->name, name) == 0 is false)
Failed getting Thread name
FAIL - test_thread_prio_dynamic
===================================================================
starting test - test_timer

    Assertion failed at /home/apboie/projects/zephyr3/zephyr/tests/cmsis_rtos_v2/src/thread_apis.c:83: thread2: (num_threads not equal to 2)
Incorrect number of cmsis rtos v2 threads
FAIL - test_timer

@andrewboie andrewboie added bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug area: ARC ARC Architecture labels Mar 18, 2019
@vonhust
Copy link

vonhust commented Mar 26, 2019

This is caused by the mismatch in stack_info, the same root cause of #13561 #14766. When fix #13561 #14766, this issue will be fixed.

@nashif nashif added priority: low Low impact/importance bug and removed priority: medium Medium impact/importance bug labels Apr 2, 2019
@nashif
Copy link
Member

nashif commented Apr 2, 2019

moving to low because blocking bug is low now.

@andrewboie
Copy link
Contributor Author

This is caused by the mismatch in stack_info, the same root cause of #13561 #14766. When fix #13561 #14766, this issue will be fixed.

#13561 has nothing to do with this..

@andrewboie
Copy link
Contributor Author

This is caused by the mismatch in stack_info, the same root cause of #13561 #14766. When fix #13561 #14766, this issue will be fixed.

And this has nothing to do with #14766 either.
The root cause is that the CMSIS test doesn't like that the stack generated is larger than the specified size. This isn't reasonable, it should complain if it is smaller.

andrewboie pushed a commit to andrewboie/zephyr that referenced this issue Apr 2, 2019
It's really not possible to design a test where we can
enforce expectations on real vs. expected stack size:

- Some platforms may increase stack size over what is expected
  due to rounding up the stack buffer area to the next power
  of two.

- Some configuration options like CONFIG_STACK_RANDOM
  carve out space in the stack buffer, resulting in a stack
  size less than what is expected.

Best we can do is just assert that the amount of space
available should be less than the total size reported.

Fixes: zephyrproject-rtos#14640

Signed-off-by: Andrew Boie <[email protected]>
nashif pushed a commit that referenced this issue Apr 3, 2019
It's really not possible to design a test where we can
enforce expectations on real vs. expected stack size:

- Some platforms may increase stack size over what is expected
  due to rounding up the stack buffer area to the next power
  of two.

- Some configuration options like CONFIG_STACK_RANDOM
  carve out space in the stack buffer, resulting in a stack
  size less than what is expected.

Best we can do is just assert that the amount of space
available should be less than the total size reported.

Fixes: #14640

Signed-off-by: Andrew Boie <[email protected]>
@abrodkin
Copy link
Collaborator

Even with #15123 in place I still see a failure in cmsis_rtos_v2 on nSIM with ARC EM:

***** Booting Zephyr OS build v2.1.0-rc1-215-gcb7974ab051f *****
Running test suite test_cmsis_v2_apis
===================================================================
starting test - test_kernel_apis
PASS - test_kernel_apis
===================================================================
starting test - test_delay
PASS - test_delay
===================================================================
starting test - test_thread_apis
E: ***** Exception vector: 0x6, cause code: 0x1, parameter 0x2
E: Address 0x80002a70
E: EV_ProtV
E: Memory read protection violation (stack checking scheme)
E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
E: Current thread: 0x800001c4 (Thread2)
E: Halting system

FWIW I'm on today's master.
@vonhust do you see that issue still as well or it's just me doing something stupid?

@vonhust
Copy link

vonhust commented Nov 21, 2019

@abrodkin this test did operations on stack which is not allowed by STACK_CHECKING, plse see #17935 , two possible fixes:

  • modify test code to remove operations on stack
  • disable arc's STACK_CHECKING for this test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: ARC ARC Architecture bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

4 participants