From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 4421D3858D32; Thu,  1 Dec 2022 11:18:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4421D3858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1669893498;
	bh=tJ2gDw9j9YoJn2A7VdgSnw8jPt5u5b3/4RLr2YVmN9I=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qvzXtupCD+lFcA5mIvH0KsaJ62aGvo1xuqw5xKfaC7ExNCWRUsE190DNkObZxFjD2
	 y4WBFuk2DunWxHd50GInGfo8ge7X+4zuhCufu4c9iZ/kkQ5R8Avr0ya2D2Irqv4AvB
	 xoEIf6fQCxZf4a4d71roXglYsuCgbzchdRb3f2a4=
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp:
 monitor exit
Date: Thu, 01 Dec 2022 11:18:18 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-29833-4717-2RkcQbGTYY@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-29833-4717@http.sourceware.org/bugzilla/>
References: <bug-29833-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #3)
> I saw it too on my CI.
>=20
> In the normal case, the monitor exit command does not cause GDB to realize
> the remote connection has closed.  It reads the RSP response ("OK") and
> that's it.  I think it does not realize the connection has closed because
> the remote connection fd is not in the event loop, and it does not try to
> read past that "OK" response.
>=20
> So, the question is, what happens differently in the failing case for GDB=
 to
> realize immediately the connection has closed?

So, the first observed difference is:
...
[event-loop] handle_file_event: invoking fd file handler `serial`^M
...
and AFAIU this is a sign that the remote connection fd is in the event loop.

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