Re: GDB hangs when calling inferior functions

[Pedro Alves <palves at redhat dot com>]

On 10/11/2017 02:01 PM, Stephen Roberts wrote:
> Hi folks,
> 
> I'm encountering a hang in GDB which I have traced back to the
> infrun_async(int) function in infrun.c, and wondered if anyone could
> shed some light on this part of the code before I raise a bug report.

This event source exists to wake up the event loop when we have
pending events to handle recorded in the thread data structures.
I.e., events that we've already pulled out of the
backend (e.g., linux-nat.c), and thus wouldn't otherwise wake up
the event loop.

> This function is a wrapper around the mark_async_event_handler and
> clear_async_event_handler functions, which set the "ready" member of
> an  async_signal_handler to 1 or 0, respectively. From what I can
> tell, this wrapper saves its argument in a file-scoped  variable
> called infrun_is_async to ensure that it only calls the  mark/clear
> functions once if it is called repeatedly with the same  argument.

That's correct.

> 
> The hang occurs when GDB tries to call inferior functions on two
> different threads with scheduler-locking turned on. The first call
> works fine, with the call to infrun_async(1) causing the
> signal_handler to be marked and the event to be handled, but then the
> event loop resets the "ready" member to zero, while leaving
> infrun_is_async set to 1. As a result, GDB hangs if the user switches
> to another thread and calls a  second function because calling
> infrun_async(1) a second time has no  effect, meaning the inferior
> call events are never handled.
> 
> I've been able to hack around this hang by resetting the
> infrun_is_async  variable to zero, but I'm hoping to find a more
> elegant solution. With that in mind, does anyone know what this logic
> is for? Most of  infrun.c just calls the mark/clear functions
> directly without going  through this interface. Which calls need to
> use this behavior, and why?

I don't recall off hand, unfortunately.  Did you look at
git log/blame?

> This issue affects all versions after 7.12 (including HEAD). For
> reference, this is my reproducer for this issue, where get_value is a
> global function:

Do you have this in gdb testsuite testcase form?
I can't promise to look at this in detail right now,
but the easier you make it to try it out, the better.

> 
> break after_thread_creation run set scheduler-locking on thread 1 
> call get_value() thread 2 call get_value() # GDB hangs here

Thanks,
Pedro Alves