[RTEMS Project] #4739: Fatal errors running GDB testcase against libdebugger

[RTEMS trac]

#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