From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
Subject: | Re: Windows crash / abort handling |
Date: | 2022-01-11 07:51:19 |
Message-ID: | 20220111075119.6ri6msoxv4z7fu73@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-01-10 10:57:00 -0500, Andrew Dunstan wrote:
> On 10/5/21 15:30, Andres Freund wrote
> > The above ends up dumping all crashes into a single file, but that can
> > probably be improved. But cdb is so gnarly that I wanted to stop looking once
> > I got this far...
FWIW, I figured out how to put the dumps into separate files by now...
> > Andrew, I wonder if something like this could make sense for windows BF animals?
> Very possibly. I wonder how well it will work on machines where I have
> more than one animal .e.g. lorikeet (cygwin) jacana (msys) and bowerbird
> (MSVC) are all on the same machine. Likewise drongo (MSVC) and fairywren
> (msys2).
Hm. I can see a few ways to deal with it. Are they running concurrently?
If not then it's easy enough to deal with.
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
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-01-11 07:57:19 | Re: Improve error handling of HMAC computations and SCRAM |
Previous Message | Sergey Shinderuk | 2022-01-11 07:50:50 | Re: Improve error handling of HMAC computations and SCRAM |