This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] Avoid step-over infinite loop in GDBServer
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, <gdb-patches at sourceware dot org>
- Date: Thu, 16 Feb 2017 22:34:53 -0500
- Subject: Re: [PATCH 2/2] Avoid step-over infinite loop in GDBServer
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=antoine dot tremblay at ericsson dot com;
- References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20161129120702.9490-2-antoine.tremblay@ericsson.com> <353b676b-5f13-6983-d25e-d07e49f89182@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Pedro Alves writes:
> On 11/29/2016 12:07 PM, Antoine Tremblay wrote:
>> - GDBServer stops on instruction A in thread 1.
>> - Deletes thread 1 single-step breakpoint.
>> - Starts a step-over of thread 1 to step-over the thread 2 breakpoint.
>> - GDBServer finishes a step-over and is at instruction B.
>> - GDBserver starts a step-over of thread 1 to step-over the thread 3
>> breakpoint at instruction B.
>> - GDBServer stops on instuction A in thread 1.
>> - GDBServer is now in an infinite loop.
>
> This sounds to me very much like a fairness issue. There were
> three threads stopped that needed to move past a breakpoint, but
> gdbserver always picks thread 1. Why?
It is a fairness issue but not between the stepping over threads,
gdbserver could pick any thread rather than thread 1 and still get into
the same loop.
The problem is one of fairness between stepping over threads and
non-stepping-over threads.
For example if all the instructions in the thread's execution
path have a breakpoint on it such that this thread always needs to
step-over and that the only way to break that loop is to let a thread
that doesn't need a step-over run then we're in an infinite loop since
GDBServer always gives precedence to the threads needing a step-over.
Thus this patch created more fairness by giving non-stepping over
threads a chance to run.
But it doesn't work... I'm not sure this can be fixed it might be more
a problem like putting a breakpoint on a mutex and wanting a thread that
depends on that mutex to continue... so more a user problem... but
non-stop-fair-events is done in a way that this can happen...
Ideas are welcome :)