#4739: Fatal errors running GDB testcase against libdebugger -------------------------------+------------------------- Reporter: Kévin Le Gouguec | Owner: Chris Johns Type: defect | Status: new Priority: normal | Milestone: Component: lib/debugger | Version: 6 Severity: normal | Keywords: Blocked By: | Blocking: -------------------------------+------------------------- Hi,
We observe fatal errors when replaying this GDB testcase against libdebugger on aarch64: <https://sourceware.org/git/?p=binutils- gdb.git;a=blob;f=gdb/testsuite/gdb.threads/next-while-other-thread- longjmps.c> {{{ $ aarch64-rtems6-g++ -o repro \ -g -x c++ \ next-while-other-thread-longjmps.c \ rtems_init.c \ -lbsd -lm -ldebugger -Wl,-gc-sections # start "repro" on a target listening on $HOST:$PORT $ aarch64-rtems6-gdb repro \ -ex 'break next-while-other-thread-longjmps.c:106' \ -ex "target remote $HOST:$PORT" \ -ex 'set variable release_debugger = 1' \ -ex 'continue' \ -ex 'next' }}} This is with rtems commit 9ed7103c618 "score: Simplify Chain_Node definition" (2022-09-23). While working on shrinking down the reproducer, we found that the exact error depends on what's happening in rtems_init.c. Attached are two variants named "minimal" and "lessminimal". "minimal" yields: {{{ *** FATAL *** fatal source: 0 (INTERNAL_ERROR_CORE) CPU: 1 fatal code: 30 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_DISABLE_LEVEL) RTEMS version: 6.0.0 RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB 3950b1e2d857a5dba054cdd230f52635f1bad4dc-modified, Newlib 9069cb9) executing thread ID: 0x0b010001 executing thread name: }}} "lessminimal" triggers a different problem, which is the one we initially observed: {{{ *** FATAL *** fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) CPU: 1 X0 = 0x0000000040bf4a90 X17 = 0x00000000400211b0 X1 = 0x000000004036bed8 X18 = 0x0000000000000014 X2 = 0x0000000040326d00 X19 = 0x0000000040bf3f60 X3 = 0x0000000040b98e00 X20 = 0x0000000000000202 X4 = 0x0000000040b98be0 X21 = 0x0000000040326900 X5 = 0x000000004036bf50 X22 = 0x0000000040326c5c X6 = 0x0000000000000000 X23 = 0x0000000040326d00 X7 = 0x000000004036c068 X24 = 0x0000000000000000 X8 = 0x0000000000000068 X25 = 0x0000000000000201 X9 = 0x0000000000000204 X26 = 0x0000000040326c58 X10 = 0x00000000fffffffa X27 = 0x000000004036bc08 X11 = 0x000000004f83f668 X28 = 0x0000000000000000 X12 = 0x0000000000000014 FP = 0x0000000040b98be0 X13 = 0x000000004f83f600 LR = 0x0000000040144a08 X14 = 0x0000000000000000 SP = 0x0000000040b98be0 X15 = 0x0000000000000000 PC = 0x0000000040144a08 X16 = 0x0000000040041c20 DAIF = 0x00000000000003c0 VEC = 0x0000000000000004 CPSR = 0x0000000060000345 ESR = EC: 0b111100 IL: 0b1 ISS: 0b0000000000000000000000000 BRK instruction execution in AArch64 state FAR = 0x0000000000000000 FPCR = 0x0000000000000000 FPSR = 0x0000000000000000 Q00 = 0x3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b3b Q01 = 0x2d2e31703a633b743a633b746e6f4376 Q02 = 0x2e31703a346632313466323132003330 Q03 = 0x00000000000000000000000000000000 Q04 = 0x00000000000000000000000000200000 Q05 = 0x00000000000004000000040000000000 Q06 = 0x00000000000000000000000000000000 Q07 = 0x80200802802008028020080280200802 Q08 = 0x00000000000000000000000000000000 Q09 = 0x00000000000000000000000000000000 Q10 = 0x00000000000000000000000000000000 Q11 = 0x00000000000000000000000000000000 Q12 = 0x00000000000000000000000000000000 Q13 = 0x00000000000000000000000000000000 Q14 = 0x00000000000000000000000000000000 Q15 = 0x00000000000000000000000000000000 Q16 = 0x40100401401004014010040140100401 Q17 = 0x00002000000000200000002008000400 Q18 = 0x00000000000000000000000000200000 Q19 = 0x00000000000000000000000000000000 Q20 = 0x00000000000000000000000000000000 Q21 = 0x00000000000000000000000000000000 Q22 = 0x00000000000000000000000000000000 Q23 = 0x00000000000000000000000000000000 Q24 = 0x00000000000000000000000000000000 Q25 = 0x00000000000000000000000000000000 Q26 = 0x00000000000000000000000000000000 Q27 = 0x00000000000000000000000000000000 Q28 = 0x00000000000000000000000000000000 Q29 = 0x00000000000000000000000000000000 Q30 = 0x00000000000000000000000000000000 Q31 = 0x00000000000000000000000000000000 RTEMS version: 6.0.0 RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB 3950b1e2d857a5dba054cdd230f52635f1bad4dc-modified, Newlib 9069cb9) executing thread ID: 0x0a010003 executing thread name: TIME }}} Our config.ini: {{{ [aarch64/xilinx_zynqmp_lp64_qemu] RTEMS_POSIX_API = True RTEMS_SMP = True }}} We have not managed to get a backtrace yet; setting a breakpoint in e.g. bsp_fatal_extension just causes GDB to hang when running "next". Let us know if there is something more we can do on our side to make these errors simpler to investigate. FWIW, we can reproduce both errors by simplifying next-while-other-thread- longjmps.c to only spawn 1 thread running thread_try_catch, instead of 10 threads running thread_longjmp and thread_try_catch. -- Ticket URL: <http://devel.rtems.org/ticket/4739> RTEMS Project <http://www.rtems.org/> RTEMS Project
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs