From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta040.useast.a.cloudfilter.net (omta040.useast.a.cloudfilter.net [44.202.169.39]) by sourceware.org (Postfix) with ESMTPS id 908CF3858C78 for ; Tue, 12 Dec 2023 19:42:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 908CF3858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 908CF3858C78 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=44.202.169.39 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702410145; cv=none; b=hPjnHdJPjNtFZzb1M/Y8zQ3xNH6mZOmRVinWZxcg05DzfuUb8xVDoFA2SW6V0l/dfUB6mUyueX991qetiG3y/bQYlJjGpbeUr4EQQEzZ/yti6Z0g2vATNCOkG7bD7qEx8I+YDs2Mr86TXeXFP+jeNMTcwt74P8fPsY2V+M4iD4U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702410145; c=relaxed/simple; bh=vrEitoL2tluB1yHLz5MeX5Qo9z07d5zwNydUTMTx4Ug=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=rm/qj3aQlhMf+9DIbjLZOaNSbQLIqnRGy5J55HB0RIeOZhApNCvWPv/N1wKPyGvVsgE0BP82+yr6a6b7Egrsn2uDvi8jvorBgDtrv7g1lw+VCof+FR1QHqU0j96RsW7Yw8bZ3vAH0tfz3gb/JBrJ7NkyxpRRdpW3EkRgfoXgWSk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-6004a.ext.cloudfilter.net ([10.0.30.197]) by cmsmtp with ESMTPS id D79hrfWXS6nOZD8e7rBBeb; Tue, 12 Dec 2023 19:42:23 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id D8e6roldPRGmSD8e7rK6yC; Tue, 12 Dec 2023 19:42:23 +0000 X-Authority-Analysis: v=2.4 cv=efcuwpIH c=1 sm=1 tr=0 ts=6578b79f a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=IkcTkHD0fZMA:10 a=e2cXIFwxEfEA:10 a=Qbun_eYptAEA:10 a=20KFwNOVAAAA:8 a=co1knQvRpXsgxXUMDh0A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jQ5JzzrnjmbU2MZDWNHEPQCthHHx3OV5FowhIMoneuk=; b=xHiWjqdN9XiGMVaqh3n+nmfxMz S9QpnkPgPmgaMe1NOQHnkr4PFdWzAoPmZuUmNkq75BAozbJIQTkc75ZL0kBtIi2TwY2pMRuq4rzeu 1C5b4IlLKxXeopKoWrm8ovD+c; Received: from 71-211-161-25.hlrn.qwest.net ([71.211.161.25]:54622 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rD8e6-0024xm-1S; Tue, 12 Dec 2023 12:42:22 -0700 From: Tom Tromey To: Alexandra =?utf-8?B?SMOhamtvdsOh?= Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/6] gdb/ser-pipe.c: Duplicate the file descriptors References: <20231117111840.2040709-1-ahajkova@redhat.com> <20231117111840.2040709-3-ahajkova@redhat.com> X-Attribution: Tom Date: Tue, 12 Dec 2023 12:42:21 -0700 In-Reply-To: <20231117111840.2040709-3-ahajkova@redhat.com> ("Alexandra =?utf-8?B?SMOhamtvdsOhIidz?= message of "Fri, 17 Nov 2023 12:18:36 +0100") Message-ID: <87v893b42q.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.161.25 X-Source-L: No X-Exim-ID: 1rD8e6-0024xm-1S X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-161-25.hlrn.qwest.net (murgatroyd) [71.211.161.25]:54622 X-Source-Auth: tom+tromey.com X-Email-Count: 12 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfIxc4LEyUYVRlIdeGcNijTKvr5Vfqnahq0xuLydOcj6aVOaBSAFXtEMHKpj49uXt6KLaM/7dY5P1S1uvAndeGh1ZUAPIonflKR5qfL+7FVdd28wvbZAL xUctInGWCNtmXzwU3qbND2lX0Kpt/WLK2JkelOWfNf+AP+gPYZdYnnVkpByqWCnx6OJEH0WaDV/wjopoO8o8+RjIwmdfSPPp6zI= X-Spam-Status: No, score=-3017.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Alexandra" =3D=3D Alexandra H=C3=A1jkov=C3=A1 = writes: Alexandra> Duplicate the numbers of STDOUT/STDIN/STDERR file descriptors Alexandra> GDB is connected to. Preserved numbers of the file descriptors Alexandra> could be then sent to the GDBserver. If GDBserver is run locally Alexandra> and will accept he numbers of the file descriptors, it can start Alexandra> the inferior connected to the same STDIN/OUT/ERR, GDB is connect= ed to. Thanks for the patch. Alexandra> + /* Preserve STDIN/STDOUT/STDERR so they won't be closed on Alexandra> + exec later, after we fork. */ Alexandra> + int saved_stdin =3D dup (STDIN_FILENO); Alexandra> + int saved_stdout =3D dup (STDOUT_FILENO); Alexandra> + int saved_stderr =3D dup (STDERR_FILENO); I wonder what should happen if any of these fail. Alexandra> @@ -128,6 +144,10 @@ pipe_open (struct serial *scb, const char *= name) Alexandra> close (err_pdes[1]); Alexandra> } =20 Alexandra> + mark_fd_no_cloexec (saved_stdout); Alexandra> + mark_fd_no_cloexec (saved_stdin); Alexandra> + mark_fd_no_cloexec (saved_stderr); Alexandra> + This happens in the child process, but due to vfork, it actually affects the parent process as well. vfork is weird. However I think this introduces a funny bug, in that these particular descriptors are marked as no-cloexec by number. So, while they are closed again in the parent: Alexandra> + close (saved_stdout); Alexandra> + close (saved_stdin); Alexandra> + close (saved_stderr); ... their numbers are preserved for not-closing, and so it's possible they could be reused and inherited by accident by some future subprocess. Probably these closes in the parent should be paired with calls to unmark_fd_no_cloexec. I'd suggest hoisting the calls to mark_fd_no_cloexec near the dup()s, too, just to make it more clear. Tom