[Bug gdb/27710] remote-notif.c:113: internal-error: void remote_async_get_pending_events_handler(gdb_client_data): Assertion `target_is_non_stop_p ()' failed

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27710

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #10)
> (In reply to Tom de Vries from comment #5)
> > We have:
> > ...
> > bool
> > target_can_async_p ()
> > {
> >   return current_inferior ()->top_target ()->can_async_p ();
> > }
> > ...
> > 
> > AFAIU, current_inferior ()->top_target () translates to:
> > ...
> > (gdb) p
> > current_inferior_.m_obj.m_target_stack.m_stack[current_inferior_.m_obj.
> > m_target_stack.m_top]
> > $16 = (target_ops *) 0x16c6cd0 <exec_ops>
> > ...
> > 
> > Exec_ops has type exec_target, which subclasses target_ops without
> > implementing a can_async_p override, so we have the default:
> > ...
> >     virtual bool can_async_p ()
> >       TARGET_DEFAULT_RETURN (false);
> > ...
> 
> Since the test is related to multi-inferior, my first question would be, is
> the current inferior the right one (one that belongs to the remote target
> receiving the notification)?
> 
> We have the remote target in notif_state->remote_target, so maybe we need to
> switch to it before calling target_is_non_stop_p.  From a quick look, it
> doesn't seem like remote_notif_process cares about the current inferior
> though.

I just stumbled upon remote_unpush_target, and it seems one remote_target can
be associated with multiple inferiors.  So at this point I'm not sure how one
would select the "right" inferior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.