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