This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug threads/22925] New: gdb assumes target can activate threads at will, causes internal error in infrun.c in 'finish_step_over'


https://sourceware.org/bugzilla/show_bug.cgi?id=22925

            Bug ID: 22925
           Summary: gdb assumes target can activate threads at will,
                    causes internal error in infrun.c in
                    'finish_step_over'
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: threads
          Assignee: unassigned at sourceware dot org
          Reporter: matthias at welwarsky dot de
  Target Milestone: ---

I can trigger an internal error in 'finish_step_over()' using openocd on an ARM
target running a ChibiOS demo. I'm using the ChibiOS rtos awareness in openocd
which presents OS threads to GDB. The sequence is basically this:

halt target,
(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 536873944 (Name: idle, State: CURRENT) _idle_thread.lto_priv.87
(p=0x0) at ../../../os/rt/src/chsys.c:72
  2    Thread 536876248 (Name: main, State: WTOREVT) chSchGoSleepTimeoutS
(newstate=<optimized out>, timeout=<optimized out>) at
../../../os/rt/src/chschd.c:384
  3    Thread 536873360 (Name: blinker 1, State: WTOREVT) chSchGoSleepTimeoutS
(newstate=<optimized out>, timeout=<optimized out>) at
../../../os/rt/src/chschd.c:384
  4    Thread 536873688 (Name: blinker 2, State: WTOREVT) chSchGoSleepTimeoutS
(newstate=<optimized out>, timeout=<optimized out>) at
../../../os/rt/src/chschd.c:384

(gdb) thread 3
[Switching to thread 3 (Thread 536873360)]
#0  chSchGoSleepTimeoutS (newstate=<optimized out>, timeout=<optimized out>) at
../../../os/rt/src/chschd.c:384
384         if (chVTIsArmedI(&vt)) {

(gdb) b
(gdb) c
Continuing.
infrun.c:5553: internal-error: int finish_step_over(execution_control_state*):
Assertion `ecs->event_thread->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 

What seems to happen is that gdb assumes that changing the current thread
inside gdb must be reflected on the target. If you set a breakpoint in frame 0
of the gdb-current thread, gdb performs a step-over on 'continue' and expects
that the server actually steps this and this thread only. This is an assumption
that can not hold. The server may not be able to influence the scheduler of the
target so that the gdb-current thread is made current, and it also cannot force
the gdb-current thread to become active without breaking assumptions of the
underlying scheduler (i.e. a thread would become active when the scheduler
doesn't expect it).

What gdb should do is:
- set the breakpoint at the appropriate frame in the gdb-current thread
- _not_ issue a step-over
- continue the target-current thread instead

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]