zephyr: sample.logger.syst.catalog.deferred_cpp fails on qemu_cortex_m0
Describe the bug
sample.logger.syst.catalog.deferred_cpp test fails on qemu_cortex_m0.
To Reproduce
scripts -v -N -M -p qemu_cortex_m0 -s samples/subsys/logging/syst/sample.logger.syst.catalog.deferred_cpp
Expected behavior
Test passes.
Logs and console output
INFO - 1173/1173 qemu_cortex_m0 samples/subsys/logging/syst/sample.logger.syst.catalog.deferred_cpp FAILED unexpected eof (qemu 0.152s)
INFO - /__w/zephyr/zephyr/twister-out/qemu_cortex_m0/samples/subsys/logging/syst/sample.logger.syst.catalog.deferred_cpp/handler.log
ERROR - SYS-T RAW DATA: 020A7F0B480000000000000000002A2A2A20426F6F74696E67205A6570687972204F53206275696C64202573202573202A2A2A0A007A65706879722D76332E322E302D3137362D676366336231306132633031350000
SYS-T RAW DATA: 230A0601040000000000000000002F6E0000
SYS-T RAW DATA: 330A060104000000000000000000166E0000
SYS-T RAW DATA: 430A060104000000000000000000006E0000
SYS-T RAW DATA: 730A060104000100000000000000E96D0000
Environment (please complete the following information):
- OS: Ubuntu 20.04
- Toolchain: Zephyr SDK 0.15.0
- Commit SHA: cf3b10a2c015631c253162b4d4a09f118d9df12c
Additional context
https://github.com/zephyrproject-rtos/zephyr/actions/runs/3180928376/jobs/5185086696#step:11:1449
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (12 by maintainers)
Commits related to this issue
- logging: workaround hard fault on Cortex-M0 with sys-t/catalog. For some reason, running sys-t with catalog message on Cortex-M0 would result in hard fault in mipi_catalog_formatter() if log_output_s... — committed to dcpleung/zephyr by dcpleung 2 years ago
- logging: workaround hard fault on Cortex-M0 with sys-t/catalog. For some reason, running sys-t with catalog message on Cortex-M0 would result in hard fault in mipi_catalog_formatter() if log_output_s... — committed to zephyrproject-rtos/zephyr by dcpleung 2 years ago
Not much toolchain experience, per se, but I’ll see if someone on the team here can have a look.
Lowering the priority after #51104 has been merged as a workaround.
Can anyone with ARM toolchain experience help to shred some light on this? Moving the file compilation order would make the hard fault go away seems like a toolchain issue.