From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-02.nifty.com (conssluserg-02.nifty.com [210.131.2.81]) by sourceware.org (Postfix) with ESMTPS id 17F5F3948A8D for ; Thu, 13 Jan 2022 10:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17F5F3948A8D Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (ae233132.dynamic.ppp.asahi-net.or.jp [14.3.233.132]) (authenticated) by conssluserg-02.nifty.com with ESMTP id 20DAucdU026735 for ; Thu, 13 Jan 2022 19:56:38 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com 20DAucdU026735 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1642071398; bh=AdGLm6B4tnf0q51ivwEivt3POjOPFo6TU0YXfxYF2qY=; h=Date:From:To:Subject:In-Reply-To:References:From; b=SMXx+mIaXQjRHruoBQ0JHEkhQSOdOUcdC0W+MfDKxKV2Q8vxveRmPAP+7THPxg/hT BoHx78Tf1Nvwji4h0qbGCqDEL3js4NoZorw2xns8ti6ttqvO/7JHj9E0r5DW+wMFSh olRjNPsbwmyzm00RUkQKraBkg4lLF+81QwW3iC9q42tS/8jFcwPAIjSZ5wab0sQ28E L+QpBs/ZVrP+jl7qoPz9HGwswqdch5Ba3j942quKwnEt83m9pEs+MpcdrUkQp/kuzA IemDcZLtx+rjmsFJvuUAyIhKvaocDUFmSjuNxSFtQMQ3OQ9Owaf+v0WdnGfMnGkMiQ NrJMsebYI4/Gw== X-Nifty-SrcIP: [14.3.233.132] Date: Thu, 13 Jan 2022 19:56:38 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: [PATCH] fhandler_pipe: add sanity limit to handle loops Message-Id: <20220113195638.d64430e6b03159c70721fb45@nifty.ne.jp> In-Reply-To: References: <622d3ac6-fa5d-965c-52da-db7a4463fffd@cornell.edu> <20211225121902.54b82f1bb0d4f958d34a8bb7@nifty.ne.jp> <20211225131242.adef568db53d561a6b134612@nifty.ne.jp> <20211226021010.a2b2ad28f12df9ffb25b6584@nifty.ne.jp> <8172019c-e048-4fe2-79c9-0b3262057d3e@cornell.edu> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 10:57:03 -0000 I am sorry for being absent for a long time. On Sun, 26 Dec 2021 10:09:57 -0500 Ken Brown wrote: > On 12/25/2021 11:56 PM, Jeremy Drake wrote: > > I set up a windows server 2022 VM last night and went nuts stressing > > pacman/GPGME. I was able to reproduce the issue there: > > > > status = 0x00000000, phi->NumberOfHandles = 8261392, n_handle = 256 > > [#####----------------------------------] 14% > > assertion "phi->NumberOfHandles <= n_handle" failed: file > > "../../.././winsup/cygwin/fhandler_pipe.cc", line 1281, function: void* > > fhandler_pipe::get_query_hdl_per_process(WCHAR*, OBJECT_NAME_INFORMATION*) > > > > So it is not something inherent in the x86_64-on-ARM64 emulation but can > > happen on native x86_64 also. > > A Google search led me to something that might explain what's going on. Look at > the function PhEnumHandlesEx2 starting at line 5713 in > > https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5152 Thank you very much for finding this, > Two interesting things: > > 1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can > return STATUS_SUCCESS with invalid handle information. See the comment starting > at line 5754, where it is shown how to detect this. and also applying the fix. > 2. You can use the ReturnLength parameter of NtQueryInformationProcess to see > how big a buffer is needed. This might be more efficient than repeatedly > doubling the buffer size. Even if ReturnLength is used, the first NtQueryInformationProcess() call and the second NtQueryInformationProcess() call will not be done in atomic, so retrying is still necessary. However, it may be more efficient as you mentioned. The similar is true also for NtQuerySystemInformation(). Do you still think it is better to use ReturnLength rather than doubling the buffer? -- Takashi Yano