-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
CI: Test #4
Closed
Closed
CI: Test #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Tyler Baker <[email protected]>
recheck |
1 similar comment
recheck |
This was referenced Sep 23, 2017
locomuco
added a commit
to locomuco/zephyr
that referenced
this pull request
Jan 12, 2018
…atibility-fix Flash: w25q: compatibility to MX flash and write register fix
ghost
mentioned this pull request
Mar 19, 2019
ccli8
pushed a commit
to ccli8/zephyr
that referenced
this pull request
Nov 18, 2022
drivers: usb: numaker: Support USBD controller driver
henrikbrixandersen
pushed a commit
to vestas-wind-systems/zephyr
that referenced
this pull request
Jan 5, 2023
krish2718
added a commit
to krish2718/zephyr
that referenced
this pull request
Sep 18, 2023
The file was removed but was still included. Signed-off-by: Chaitanya Tata <[email protected]>
krish2718
added a commit
to krish2718/zephyr
that referenced
this pull request
Sep 18, 2023
The file was removed but was still included. Signed-off-by: Chaitanya Tata <[email protected]>
krish2718
added a commit
to krish2718/zephyr
that referenced
this pull request
Sep 18, 2023
The file was removed but was still included. Signed-off-by: Chaitanya Tata <[email protected]>
AbhinavMir
added a commit
to AbhinavMir/zephyr
that referenced
this pull request
Jan 27, 2024
# This is the 1st commit message: posix: Tests for putmsg Add in tests for putmsg impl and headers Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#2: posix: Tests for putmsg Add tests for implentation and header file. Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#3: posix: fix stropts_h.c faulty imports and function usage # This is the commit message zephyrproject-rtos#4: posix: fix streams config symbol Makes more sense to use CONFIG_POSIX_STROPTS Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#5: Revert "posix: fix streams config symbol" This reverts commit aa03b70. Signed-off-by: Abhinav Srivastava <[email protected]> # This is the commit message zephyrproject-rtos#6: Update tests/posix/headers/src/stropts_h.c Co-authored-by: Chris Friedt <[email protected]>
marc-hb
added a commit
to marc-hb/zephyr
that referenced
this pull request
Feb 3, 2024
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A practical use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is immediately available in the logs without even running anything: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` Full stack trace When running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb ./zephyr.exe backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>
marc-hb
added a commit
to marc-hb/zephyr
that referenced
this pull request
Feb 3, 2024
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A practical use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is immediately available in the logs without even running anything: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` Full stack trace When running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb ./zephyr.exe backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>
marc-hb
added a commit
to marc-hb/zephyr
that referenced
this pull request
Feb 3, 2024
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A good, sample use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is now immediately available in test logs without even running anything locally: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb @ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623 ZEPHYR FATAL ERROR: 3 ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` The full stack trace is now immediately available when running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb build-fuzz/zephyr/zephyr.exe run backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>
marc-hb
added a commit
to marc-hb/zephyr
that referenced
this pull request
Feb 5, 2024
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A good, sample use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is now immediately available in test logs without even running anything locally: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb @ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623 ZEPHYR FATAL ERROR: 3 ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` The full stack trace is now immediately available when running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb build-fuzz/zephyr/zephyr.exe run backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>
marc-hb
added a commit
to marc-hb/zephyr
that referenced
this pull request
Feb 5, 2024
Flush all messages and invoke `abort()` when a k_panic() or k_oops() is hit in native_posix mode. One of the main purposes of `native_posix` is to provide debug convenience. When running in a debugger, `abort()` stops execution which provides a backtrace and the ability to inspect all variables. A good, sample use case is fuzzing failures in SOF, see an example in: thesofproject/sof#8632 In such a case, this commit adds value even before using a debugger. Without this commit, confusingly meaningless stack trace: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb Exiting due to fatal error ==314134== ERROR: libFuzzer: fuzz target exited #0 0x81d9637 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9637) #1 0x80cc42b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc42b) zephyrproject-rtos#2 0x80ab79e in fuzzer::Fuzzer::ExitCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab864 in fuzzer::Fuzzer::StaticExitCallback() (zephyr.exe+ zephyrproject-rtos#4 0xf783dfe8 (/usr/lib32/libc.so.6+0x3dfe8) zephyrproject-rtos#5 0xf783e1e6 in exit (/usr/lib32/libc.so.6+0x3e1e6) zephyrproject-rtos#6 0x82a5488 in posix_exit boards/posix/native_posix/main.c:51:2 SUMMARY: libFuzzer: fuzz target exited ``` Thanks to this commit the `k_panic()` location is now immediately available in test logs without even running anything locally: ``` INFO: seed corpus: files: 1097 min: 1b max: 428b total: 90853b rss: 58Mb @ WEST_TOPDIR/sof/src/ipc/ipc3/handler.c:1623 ZEPHYR FATAL ERROR: 3 ==315176== ERROR: libFuzzer: deadly signal LLVMSymbolizer: error reading file: No such file or directory #0 0x81d9647 in __sanitizer_print_stack_trace (zephyr.exe+0x81d9647) #1 0x80cc43b in fuzzer::PrintStackTrace() (zephyr.exe+0x80cc43b) zephyrproject-rtos#2 0x80ab6be in fuzzer::Fuzzer::CrashCallback() FuzzerLoop.cpp.o zephyrproject-rtos#3 0x80ab77b in fuzzer::Fuzzer::StaticCrashSignalCallback() zephyrproject-rtos#4 0xf7f3159f (linux-gate.so.1+0x59f) zephyrproject-rtos#5 0xf7f31578 (linux-gate.so.1+0x578) zephyrproject-rtos#6 0xf788ea16 (/usr/lib32/libc.so.6+0x8ea16) zephyrproject-rtos#7 0xf783b316 in raise (/usr/lib32/libc.so.6+0x3b316) zephyrproject-rtos#8 0xf7822120 in abort (/usr/lib32/libc.so.6+0x22120) zephyrproject-rtos#9 0x82afbde in ipc_cmd src/ipc/ipc3/handler.c:1623:2 NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` The full stack trace is now immediately available when running zephyr.exe in gdb: ``` ./scripts/fuzz.sh -- -DEXTRA_CFLAGS="-O0 -g3" gdb build-fuzz/zephyr/zephyr.exe run backtrace zephyrproject-rtos#2 0xf783b317 in raise () from /usr/lib32/libc.so.6 zephyrproject-rtos#3 0xf7822121 in abort () from /usr/lib32/libc.so.6 zephyrproject-rtos#4 0x082afbdf in ipc_cmd (_hdr=0x8b...) at src/ipc/ipc3/handler.c:1623 zephyrproject-rtos#5 0x082fbf4b in ipc_platform_do_cmd (ipc=0x8b161c0) at src/platform/posix/ipc.c:162 zephyrproject-rtos#6 0x082e1e07 in ipc_do_cmd (data=0x8b161c0 <heapmem+1472>) at src/ipc/ipc-common.c:328 zephyrproject-rtos#7 0x083696aa in task_run (task=0x8b161e8 <heapmem+1512>) at zephyr/include/rtos/task.h:94 zephyrproject-rtos#8 0x083682dc in edf_work_handler (work=0x8b1621c <heapmem+1564>) at zephyr/edf_schedule.c:32 zephyrproject-rtos#9 0x085245af in work_queue_main (workq_ptr=0x8b15b00 <edf_workq>,...) at zephyr/kernel/work.c:688 zephyrproject-rtos#10 0x0823a6bc in z_thread_entry (entry=0x8523be0 <work_queue_main>,.. at zephyr/lib/os/thread_entry.c:48 zephyrproject-rtos#11 0x0829a6a1 in posix_arch_thread_entry (pa_thread_status=0x8630648 .. at zephyr/arch/posix/core/thread.c:56 zephyrproject-rtos#12 0x0829c043 in posix_thread_starter (arg=0x4) at zephyr/arch/posix/core/posix_core.c:293 zephyrproject-rtos#13 0x080f6041 in asan_thread_start(void*) () zephyrproject-rtos#14 0xf788c73c in ?? () from /usr/lib32/libc.so.6 ``` Signed-off-by: Marc Herbert <[email protected]>
jeppenodgaard
added a commit
to jeppenodgaard/zephyr
that referenced
this pull request
Apr 30, 2024
…support-for-measurement-of-o-2-pr-follow-up Ns 380 support for measurement of o 2 pr follow up
ldenefle
added a commit
to ldenefle/zephyr
that referenced
this pull request
Jun 20, 2024
github: shut doc building
swkim101
added a commit
to swkim101/zephyr
that referenced
this pull request
Oct 10, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in over 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d) zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in '/mnt/hdd1/sungwoo/zephyr-afl/zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c) zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc) zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6) zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b) zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd) zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>
swkim101
added a commit
to swkim101/zephyr
that referenced
this pull request
Oct 23, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in over 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d) zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c) zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc) zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6) zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b) zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd) zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>
swkim101
added a commit
to swkim101/zephyr
that referenced
this pull request
Oct 24, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d) zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c) zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc) zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6) zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b) zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd) zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>
aescolar
pushed a commit
that referenced
this pull request
Oct 25, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) #1 0x4d697d (/root/zephyr.exe+0x4d697d) #2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) #1 0x530192 (/root/zephyr.exe+0x530192) #2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) #1 0x530192 (/root/zephyr.exe+0x530192) #2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) #1 0x52f36c (/root/zephyr.exe+0x52f36c) #2 0x5371dc (/root/zephyr.exe+0x5371dc) #3 0x5312a6 (/root/zephyr.exe+0x5312a6) #4 0x52ed7b (/root/zephyr.exe+0x52ed7b) #5 0x52eddd (/root/zephyr.exe+0x52eddd) #6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>
anhuba
pushed a commit
to anhuba/zephyr
that referenced
this pull request
Oct 28, 2024
hci_packet_complete(buf, buf_size) should check whether buf_size is enough. For instance, hci_packet_complete can receive buf with buf_size 1, leading to the buffer overflow in cmd->param_len, which is buf[3]. This can happen when rx_thread() receives two frames in 512 bytes and the first frame size is 511. Then, rx_thread() will call hci_packet_complete() with 1. ==5==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000ad81c2 at pc 0x0000005279b3 bp 0x7fffe74f5b70 sp 0x7fffe74f5b68 READ of size 2 at 0x000000ad81c2 thread T6 #0 0x5279b2 (/root/zephyr.exe+0x5279b2) zephyrproject-rtos#1 0x4d697d (/root/zephyr.exe+0x4d697d) zephyrproject-rtos#2 0x7ffff60e5daa (/lib/x86_64-linux-gnu/libc.so.6+0x89daa) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) 0x000000ad81c2 is located 2 bytes to the right of global variable 'rx_thread.frame' defined in 'zephyr/drivers/bluetooth/hci/userchan.c' (0xad7fc0) of size 512 SUMMARY: AddressSanitizer: global-buffer-overflow (/root/zephyr.exe+0x5279b2) Thread T6 created by T2 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T2 created by T1 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x530192 (/root/zephyr.exe+0x530192) zephyrproject-rtos#2 0x4dcc22 (/root/zephyr.exe+0x4dcc22) Thread T1 created by T0 here: #0 0x48c17c (/root/zephyr.exe+0x48c17c) zephyrproject-rtos#1 0x52f36c (/root/zephyr.exe+0x52f36c) zephyrproject-rtos#2 0x5371dc (/root/zephyr.exe+0x5371dc) zephyrproject-rtos#3 0x5312a6 (/root/zephyr.exe+0x5312a6) zephyrproject-rtos#4 0x52ed7b (/root/zephyr.exe+0x52ed7b) zephyrproject-rtos#5 0x52eddd (/root/zephyr.exe+0x52eddd) zephyrproject-rtos#6 0x7ffff6083c89 (/lib/x86_64-linux-gnu/libc.so.6+0x27c89) (BuildId: 2e01923fea4ad9f7fa50fe24e0f3385a45a6cd1c) ==5==ABORTING Signed-off-by: Sungwoo Kim <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Test for checkpatch and sanitycheck.
Signed-off-by: Tyler Baker [email protected]