Re: Windows crash / abort handling
От | Andres Freund |
---|---|
Тема | Re: Windows crash / abort handling |
Дата | |
Msg-id | 20220111075119.6ri6msoxv4z7fu73@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Windows crash / abort handling (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Windows crash / abort handling
|
Список | 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
В списке pgsql-hackers по дате отправления: