From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id B13853858D32; Mon, 15 Jan 2024 14:28:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B13853858D32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1705328928; bh=iDnO7/55HPwAXYc391mCejDltUVEtWsRMe3um2Tl08s=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=avK+h/HbIzbQnJFOCy/S8mKYvr5+RpJz5NrG5t2e04We6U49ag3kTr44nP2PeIWlF TgryhKyiSFVFTK38Rl36ea/7fAf9idbKDQ2dZYRH8KSqOprEkcqIgMwG0osxP3MAAS jfkF5am7lXYjQfwpFCxs5FLwX9XO2hRaJHeS89qI= Received: by calimero.vinschen.de (Postfix, from userid 500) id E3E75A80D09; Mon, 15 Jan 2024 15:28:46 +0100 (CET) Date: Mon, 15 Jan 2024 15:28:46 +0100 From: Corinna Vinschen To: cygwin-patches@cygwin.com Subject: Re: [PATCH 1/5] Cygwin: Make 'ulimit -c' control writing a coredump Message-ID: Reply-To: cygwin-patches@cygwin.com Mail-Followup-To: cygwin-patches@cygwin.com References: <20240112140958.1694-1-jon.turney@dronecode.org.uk> <20240112140958.1694-2-jon.turney@dronecode.org.uk> <0e5b64f3-9d36-438d-96ad-20d231bccfeb@dronecode.org.uk> <3dafa845-a583-4b47-b0d6-3b16f46c8a67@dronecode.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3dafa845-a583-4b47-b0d6-3b16f46c8a67@dronecode.org.uk> List-Id: On Jan 15 13:27, Jon Turney wrote: > On 15/01/2024 09:46, Corinna Vinschen wrote: > > On Jan 13 14:20, Jon Turney wrote: > > > On 12/01/2024 14:09, Jon Turney wrote: > > > > + > > > > + PWCHAR cp = dumper_command; > > > > + cp = wcpcpy (cp, L"\""); > > > > + cp = wcpcpy (cp, dll_dir); > > > > + cp = wcpcpy (cp, L"\\dumper.exe"); > > > > + cp = wcpcpy (cp, L"\" "); > > > > + cp = wcpcpy (cp, L"\""); > > > > + cp = wcpcpy (cp, global_progname); > > > > > > I wonder if this should be program_invocation_short_name, so that the > > > coredump is created in the cwd, rather than next to the executable. > > > > program_invocation_short_name would be nice, but does it really matter? > > > > Because... > > > > > But then, there's then no way to get similar behaviour if you decide you > > > want to use minidumps instead (by setting CYGWIN="error_start=minidumper"), > > > as the first argument to dumper/minidump is the full path to the program (to > > > match the 'prog procID' style of invoking gdb), but they only use it to add > > > an .core/.dmp extension to name the file to write. > > > > > > I guess that could by fixed by adding an option to the dumpers to strip > > > paths, or more control about how the JIT command is formatted. > > > > dumper/minidumper are both called with the current working directory set > > to the ... current working directory, right? With the full pathname as > > input, and the CWD already set the same as the dumped application, they > > can easily generate any target path for the corefile they like. > > > > Given the actual path of the corefile can be generated by the dumpers, > > the question is how to specify where to store the corefile. For instance > > > > - no option: CWD > > - some option -c/--coredir for anywhere else > > > > Under Linux versions using systemd, corefiles are by default not stored > > in the CWD anymore, but to /var/lib/systemd/coredump, so there is a > > use case for arbitrary corefile paths. > > Yeah, I guess an option to the dumper to control where the file is written > is probably the best way to address this, which is something which can > perhaps be added later... Yeah. In that case we should write the coredump to CWD for the time being and improve that for 3.6, ok? Corinna