If we delete an inferior with delete_inferior (which tries to deletes all of
its child threads) while one of its threads is selected, delete_thread will
refuse to unlist it, but will instead tag it as exited.  When we get to do a
generic_mourn_inferior, we will no longer find the inferior listed, so this
exited thread was left behind, but we do set inferior_ptid to null_ptid.  This
happens to then trigger an internal error in mi-main.c:mi_execute_command: ...

      if (/* The notifications are only output when the top-level
	     interpreter (specified on the command line) is MI.  */      
	  ui_out_is_mi_like_p (interp_ui_out (top_level_interpreter ()))
	  /* Don't try report anything if there are no threads -- 
	     the program is dead.  */
	  && thread_count () != 0
	  /* -thread-select explicitly changes thread. If frontend uses that
	     internally, we don't want to emit =thread-selected, since
	     =thread-selected is supposed to indicate user's intentions.  */
	  && strcmp (command->command, "thread-select") != 0)
	{
	  struct mi_interp *mi = top_level_interpreter_data ();
	  struct thread_info *ti = inferior_thread ();
                                   ^^^^^^^^^^^^^^^^^^

... here, since inferior_ptid was pointing at null_ptid, and, thread_count()
returned 1.  null_ptid is never a listed thread, so inferior_thread rightfully
asserts.

To fix this, we either set inferior_ptid to null_ptid before deleting the
inferior when we want to prevent this, or, we defer deleting the inferior to
generic_mourn_inferior, which does just that.  I've done the latter.  This
also goes in the direction of what we were talking about in the infrun
cleanup thread, about the inferior being already gone when we handle an
inferior exit event.

Tested against an x86_64-linux-gnu gdbserver.  Checked in.

-- 
Pedro Alves