Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7OSC-0007ZE-SO for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 21:13:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7OSB-0002Vx-Ou for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jan 2022 21:13:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7OSA-0002Vn-6r for pgsql-hackers@lists.postgresql.org; Tue, 11 Jan 2022 21:13:15 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7OS5-0007QV-4x for pgsql-hackers@postgresql.org; Tue, 11 Jan 2022 21:13:13 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 33CFF3200A2F; Tue, 11 Jan 2022 16:13:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 11 Jan 2022 16:13:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=k7KlZ80bqsNtITXc2mBVKXCcIlE Hx6EVrWRECevTrg4=; b=TOu+bC7IOT/hj5BycBu41qISee/X1WpYqVCowraDLxS oHiEkIWw4DG2a5z3g1Hugredr4xk5Nx+kPugqdcCdU67vRtVDCbauB/+KuX1jMZN 4dFhUWyNNI3hNsoDtDD6xCEYDdpGh4kuXd1gSug0b0C7dNjUthTFyn28KIPLpp28 xRLBojINflout+M7rh18iJ02IBeSXgNIaQq6XtpyA6xW7gU7yXkcY8IIgHPrwy5V yu/hu+6hproYDgVnvOU+M70AvdD7OPjtSQg8AcOgLPKImBU5tK15ExT+G6QwcmX0 BcE/7LxAbVO0jgzuOcUj0N8XHCvNfVDOpLYkciUd09g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=k7KlZ8 0bqsNtITXc2mBVKXCcIlEHx6EVrWRECevTrg4=; b=GmnkY6yYUOr+mMduMDwXHs igLb+AScZsQ7NCKRRH1f3OjhIF2a0JYc6XeWU+zyYrK17BsxYEgi3j+BbPOfklrG fuGM/LfNsh3odzC1z95Ww2hN9EB491t7aMJDlVL5i2bKimBTbTTrlFgmsgglLwUT rOSE+46C0OS0jmGp715bd+A81Ipd999+p9e/8DEuXS2hSKBUTmH6VGZ5evI+O9Ja uo6duzAlkvnfO3DxIUFxhNzG18/sMAzSEIkgrdC/UZ5aU+huH7joD/iYOwQOlwKv Dg4vcX016fU8SlLhSb6cyHMkOr1PG48p0A2E5fHADfdYfF3dS/snoUOee0VqdWAw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehfedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrf grthhtvghrnhepvdfhgfekjedugfejtdeviefgheeuueelhedugfffvddvhfevudefudej ffekteeunecuffhomhgrihhnpehmihgtrhhoshhofhhtrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgr iigvlhdruggv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jan 2022 16:13:04 -0500 (EST) Date: Tue, 11 Jan 2022 13:13:03 -0800 From: Andres Freund To: Andrew Dunstan Cc: pgsql-hackers@postgresql.org, Tom Lane , Craig Ringer Subject: Re: Windows crash / abort handling Message-ID: <20220111211303.34vr25whig76srza@alap3.anarazel.de> References: <20211005193033.tg4pqswgvu3hcolm@alap3.anarazel.de> <56014fa7-be7f-86f4-9f25-e8341342d5f5@dunslane.net> <20220111075119.6ri6msoxv4z7fu73@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2022-01-11 12:01:42 -0500, Andrew Dunstan wrote: > On 1/11/22 02:51, Andres Freund wrote: > > It'd be a bit of a fight with cdb's awfully documented and quirky > > scripting [1], but the best solution would probably be to just use an > > environment variable from the target process to determine the dump > > location. Then each buildfarm config could set a BF_BACKTRACE_LOCATION > > variable or such... > > > > [1] So there's !envvar. But that yields a string like > > BF_BACKTRACE_LOCATION = value of environment variable when set to an > > alias. And I haven't found an easy way to get rid of the "variablename > > = ". There is .foreach /pS [2] which could be used to skip over the > > varname =, but that then splits on all whitespaces. Gah. > > > > [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-foreach > > > > Ugly as heck. Indeed. I think I figured it out: 0:000> !envvar frak frak = C:\Program Files\Application Verifier\ 0:000> ad /q path; .foreach /pS 2 (component {!envvar frak}){ .if (${/d:path}) {aS ${/v:path} ${/f:path} ${component}} .else {aS ${/v:path} ${component}}}; .block {.echo ${path}} C:\Program Files\Application Verifier\ I mean, no explanation needed, right? > But in theory these animals could be running in parallel, and in theory > each animal could have more than one branch being run concurrently. In > fact locking them against each other can be difficult/impossible. The environment variable solution directing dumps for each animal / branch to different directories should take care of that, right? Do you have a preference where a script file implementing the necessary cdb.exe commands would reside? It's getting too long to comfortably implement it inside the registry setting itself... That script would be used by all branches, rather than be branch specific. Greetings, Andres Freund