This is the mail archive of the gdb-testers@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]

[binutils-gdb] gdb: Mark async event handler when event is already pending


*** TEST RESULTS FOR COMMIT 9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70 ***

Author: Andrew Burgess <andrew.burgess@embecosm.com>
Branch: master
Commit: 9516f85aea1d9a34d1cd3f59b7b9eeb590e58c70

gdb: Mark async event handler when event is already pending

In PR22882 inferior functions are called on different threads while
scheduler-locking is turned on.  This results in a hang.  This was
discussed in this mailing list thread:

    https://sourceware.org/ml/gdb/2017-10/msg00032.html

The problem is that when the thread is set running in order to execute
the inferior call, a call to target_async is made.  If the target is
not already registered as 'target_async' then this will install the
async event handler, AND unconditionally mark the handler as having an
event pending.

However, if the target is already registered as target_async then the
event handler is not installed (its already installed) and the
handler is NOT marked as having an event pending.

If we try to set running a thread that already has a pending event,
then we do want to set target_async, however, there will not be an
external event incoming (the thread is already stopped) so we rely on
manually marking the event handler as having a pending event in order
to see the threads pending stop event.  This is fine, if, at the point
where we call target_async, the target is not already marked as async.
But, if it is, then the event handler will not be marked as ready, and
the threads pending stop event will never be processed.

A similar pattern of code can be seen in linux_nat_target::resume,
where, when a thread has a pending event, the call to target_async is
followed by a call to async_file_mark to ensure that the pending
thread event will be processed, even if target_async was already set.

gdb/ChangeLog:

	PR gdb/22882
	* infrun.c (resume_1): Add call to mark_async_event_handler.

gdb/testsuite/ChangeLog:

	* gdb.threads/multiple-successive-infcall.exp: Remove kfail case,
	rewrite test to describe action performed, rather than possible
	failure.


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