Subject: Re: Windows crash / abort handling

From: Andres Freund <[email-masked]>
Date: Mon, 10 Jan 2022 23:51:19 -0800

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: Andrew Dunstan <[email-masked]>
Date: Tue, 11 Jan 2022 12:01:42 -0500

> [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-foreach

Ugly as heck. I normally don't use locations with spaces in them. Let's
assume we don't have to deal with that issue at least.

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. From
experience, three different perls might not agree on how file locking
works ... In the case of fairywren/drongo I have had to set things up so
that there is a single batch file that runs one job after the other.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com