Closed duanlangtaosha closed 1 year ago
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
Is there a minimal repro recipe? This works fine.
twister -i -p qemu_riscv32 -T tests/lib/cpp/libcxx
I've managed to run the code you provided on qemu_riscv32
.
It appears that using C++ exceptions requires a larger stack.
I'm using Zephyr version 56a8123eed2eb27
.
I have reproduced the source code of the application based on the information provided in the issue.
I've also modified samples/synchronization/prj.conf
accordingly:
CONFIG_STDOUT_CONSOLE=y
# enable to use thread names
CONFIG_THREAD_NAME=y
CONFIG_SCHED_CPU_MASK=y
CONFIG_CPP=y
CONFIG_STD_CPP11=y
CONFIG_GLIBCXX_LIBCPP=y
CONFIG_CPP_EXCEPTIONS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_STDOUT_CONSOLE=y
We already know this doesn't work. However, after I modified the stack size this way:
diff --git a/samples/synchronization/src/main.c b/samples/synchronization/src/main.c
index e9735d9781..b5b09b12c8 100644
--- a/samples/synchronization/src/main.c
+++ b/samples/synchronization/src/main.c
@@ -19,7 +19,7 @@
#define PIN_THREADS (IS_ENABLED(CONFIG_SMP) && IS_ENABLED(CONFIG_SCHED_CPU_MASK))
/* size of stack area used by each thread */
-#define STACKSIZE 1024
+#define STACKSIZE 2800
/* scheduling priority used by each thread */
#define PRIORITY 7
The application works, and the output I'm getting is:
*** Booting Zephyr OS build zephyr-v3.4.0-1749-g568cb5f96e55 ***
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_a: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
thread_b: Hello World from cpu 0 on qemu_riscv32!
caught an exception!
I don't know why exactly the default stack size is not sufficient on RISC-V while it is sufficient on ARM. Nonetheless, it looks like C++ exceptions are not necesssarily mishandled but rather need a larger stack.
I don't know why exactly the default stack size is not sufficient on RISC-V while it is sufficient on ARM.
Typically we want to make the default stack sizes as small as possible, rather than large enough to ensure that any possible application builds properly.
Nonetheless, it looks like C++ exceptions are not necesssarily mishandled but rather need a larger stack.
It sounds like you have solved your problem 👍
Describe the problem
I tested a simple C++ exception capture example, it is normal under the arm platform, but the program will crash under the RISCV platform.
The zephyr version is as follows:
The SDK version is as follows:
sample code
test_exception.cpp
main.c
compilation process
Modify the default configuration, only modify
GLIBCXX_LIBCPP
andCPP_EXCEPTIONS
,NEWLIB_LIBC
, the detailed configuration is as followsThe result of the program execution is as follows, the program has currently crashed
When I debugged, I found that the program crashed in the
_Unwind_Find_FDE
functionBut when I change the platform and follow the same configuration above, the execution result is normal again
The normal execution results are as follows: