This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/22925] New: gdb assumes target can activate threads at will, causes internal error in infrun.c in 'finish_step_over'
- From: "matthias at welwarsky dot de" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 05 Mar 2018 12:26:07 +0000
- Subject: [Bug threads/22925] New: gdb assumes target can activate threads at will, causes internal error in infrun.c in 'finish_step_over'
- Auto-submitted: auto-generated
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.