Hi, On 2019-05-02 11:02:03 -0400, Tom Lane wrote: > In the past week, four different buildfarm members have shown > non-reproducing segfaults in the "select infinite_recurse()" > test case, rather than the expected detection of stack overrun > before we get to the point of a segfault.
I was just staring at bonito's failure in confusion. > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bonito&dt=2019-05-01%2023%3A05%3A36 > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=takin&dt=2019-05-01%2008%3A16%3A48 > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=buri&dt=2019-04-27%2023%3A54%3A46 > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=demoiselle&dt=2019-04-27%2014%3A55%3A52 > > They're all on HEAD, and they all look like > > 2019-05-01 23:11:00.145 UTC [13933:65] LOG: server process (PID 17161) was > terminated by signal 11: Segmentation fault > 2019-05-01 23:11:00.145 UTC [13933:66] DETAIL: Failed process was running: > select infinite_recurse(); > > I scraped the buildfarm database and verified that there are no similar > failures for at least three months back; nor, offhand, can I remember ever > having seen this test fail in many years. So it seems we broke something > recently. No idea what though. I can't recall any recent changes to relevant area of code. > (Another possibility, seeing that these are all members of Mark's PPC64 > flotilla, is that there's some common misconfiguration --- but it's hard > to credit that such a problem would only affect HEAD not the back > branches.) Hm, I just noticed: 'HEAD' => [ 'force_parallel_mode = regress' ] on all those animals. So it's not necessarily the case that HEAD and backbranch runs are behaving all that identical. Note that isn't a recent config change, so it's not an explanation as to why they started to fail only recently. Greetings, Andres Freund
