GDB hangs when calling inferior functions

[Stephen Roberts <Stephen dot Roberts at arm dot com>]

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 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.

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?

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:

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

Thanks and Regards,
Stephen Roberts.