test:mimxrt10xx_evk:tests/kernel/mem_protect/stackprot: get unexpected Stacking error

[hakehuang]

Describe the bug
when coduction the tests/kernel/mem_protect/stackprot case in RT series board e.g mimxrt1060_evk, there is a MPU FAULT at the end of test.

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=mimxrt1060_evk ..
3. make
4. make flash

Expected behavior
test ends cleanly.

Impact
MPU

Screenshots or console output

start stack at 0x80001e00 !!!
*** Booting Zephyr OS version 2.3.0-rc1  ***
Running test suite stackprot
===================================================================
starting test - test_create_alt_thread
Starts alternate_thread
alternate_thread: Input string is too long and stack overflowed!

E: r0/a1:  0x00000002  r1/a2:  0x00000000  r2/a3:  0xa06f6ff4
E: r3/a4:  0x00000000 r12/ip:  0x60002f35 r14/lr:  0x60002857
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x6000d818
E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
E: Current thread: 0x800000a8 (unknown)
PASS - test_create_alt_thread
===================================================================
starting test - test_stackprot
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
PASS - test_stackprot
=========E: ***** MPU FAULT *****
E:   Stacking error (context area might be not valid)
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/arch/arm/core/aarch32/cortex_m/fault.c:304
	Stacking error not a stack fail

E: ***** HARD FAULT *****
E:   Fault escalation (see below)
E: ***** MPU FAULT *****
E:   Stacking error (context area might be not valid)
E: r0/a1:  0x00000004  r1/a2:  0x00000130  r2/a3:  0x00000000
E: r3/a4:  0x00000004 r12/ip:  0x00000000 r14/lr:  0x600066c3
E:  xpsr:  0x61000004
E: Faulting instruction address (r15/pc): 0x60003df2
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x8000040c (main)
wrong error type

================================ End =================================

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephyr SDK,
• v2.3.0-RC1

[hakehuang]

@MaureenHelm

[ioannisg]

This is due to a stack overflow in the main thread, for IMX platforms, @andrewboie, I am not sure if this is strictly related to the STACK_CANARIES feature which is enabled in this test. If I set MAIN_STACK_SIZE to 1024, this will pass.

But I only see this problem with the iMX platforms, so I am not sure what the best way is to increase main stack size here: do it for iMX platforms, in general, or do it for this test only (but for any platform).

FYI @MaureenHelm

[ioannisg]

BTW, the failed assertion you see in the log (which should never happen, despite any stacking errors in the test) is covered in #25612

[andrewboie]

This is due to a stack overflow in the main thread, for IMX platforms, @andrewboie, I am not sure if this is strictly related to the STACK_CANARIES feature which is enabled in this test. If I set MAIN_STACK_SIZE to 1024, this will pass.

@ioannisg Stack canaries increase stack usage, due to the need to push the sentinel values on every stack frame. So if the test was near the limit, enabling canaries would push it over the limit.

Do we understand yet why this is just failing on mimxrt1060_evk and not any of our emulated targets?

[carlescufi]

Do we understand yet why this is just failing on mimxrt1060_evk and not any of our emulated targets?

This seems to run fine on all QEMU-based Arm targets.

[MaureenHelm]

Do we understand yet why this is just failing on mimxrt1060_evk and not any of our emulated targets?

This seems to run fine on all QEMU-based Arm targets.

It also runs fine on frdm_k64f and lpcxpresso55s69_cpu0.

@erwango, can you run this test on one of your M7 boards?

[jfischer-no]

passes on sam_e70_xplained (Cortex-M7 Processor)

*** Booting Zephyr OS build v2.3.0-rc1-320-g0ec24ca86718  ***
Running test suite stackprot
===================================================================
starting test - test_create_alt_thread
Starts alternate_thread
alternate_thread: Input string is too long and stack overflowed!

E: r0/a1:  0x00000002  r1/a2:  0x00000000  r2/a3:  0x002f6ff4
E: r3/a4:  0x00000000 r12/ip:  0x00400dd9 r14/lr:  0x004006fb
E:  xpsr:  0x61000000
E: Faulting instruction address (r15/pc): 0x004097c0
E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
E: Current thread: 0x204000a8 (unknown)
PASS - test_create_alt_thread
===================================================================
starting test - test_stackprot
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
test_stackprot: Stack ok
PASS - test_stackprot
===================================================================
Test suite stackprot succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

[ioannisg]

Right @jfischer-phytec-iot , I tested it, as well, on SAM E70.
Test also passes on SAM3X, LPCXPRESSO_54114, and all nRF platforms.

Do we understand yet why this is just failing on mimxrt1060_evk and not any of our emulated targets?

@andrewboie just a note; in this test, main thread stack overflows on several imx SoCs, not only mimxrt1060.

Also, we do increase MAIN_STACK_SIZE configuration when we do COVERAGE_GCOV, or even directly in BOARDS' defconfigs (e.g. for several vendor boards, and including some ARM Qemu targets), so that's why the test is passing in qemu targets; it runs with higher-than-the-default main thread stack size. We are not consistent at all with respect to main thread stack size in our targets.

My point is: if we all agree that Stack Canaries do have an effect on stack usage, then it is better to increase the Main Thread Stack size in this particular test, rather than increasing the default Main Stack Size for all iMX platforms.

This setting will increase the ram usage of the test and might, eventually, require the test to be filtered-out for some platforms with little SRAM: but I think we can live with this. Currently the test builds on 236 board targets in the tree. When I increase Main Stack size to 2048, the test still builds successfully on all of these boards. It's good coverage, IMO.

[MaureenHelm]

My point is: if we all agree that Stack Canaries do have an effect on stack usage, then it is better to increase the Main Thread Stack size in this particular test, rather than increasing the default Main Stack Size for all iMX platforms.

yes

passes on sam_e70_xplained (Cortex-M7 Processor)

thanks @jfischer-phytec-iot

[andrewboie]

My point is: if we all agree that Stack Canaries do have an effect on stack usage, then it is better to increase the Main Thread Stack size in this particular test, rather than increasing the default Main Stack Size for all iMX platforms.

This is known -- stack canaries work by pushing the extra sentinel value onto every stack frame.

[dleach02]

I suggest we accept #25617 as the fix for this bug report and allow it to close.