Re: segfault in geqo on experimental gcc animal
От | Fabien COELHO |
---|---|
Тема | Re: segfault in geqo on experimental gcc animal |
Дата | |
Msg-id | alpine.DEB.2.21.1911100853540.10308@lancre обсуждение исходный текст |
Ответ на | segfault in geqo on experimental gcc animal (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: segfault in geqo on experimental gcc animal
|
Список | pgsql-hackers |
Hello Andres, > I don't think there's been any relevant code changes since the last > success. > > last success: > 2019-11-09 09:20:28.346 CET [28785:1] LOG: starting PostgreSQL 13devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.0.020191102 (experimental), 64-bit > > first failure: > 2019-11-09 11:19:36.277 CET [42512:1] LOG: starting PostgreSQL 13devel on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.0.020191109 (experimental), 64-bit > > > so it sure looks like a gcc upgrade caused the failure. But it's not > clear wheter it's a compiler bug, or some undefined behaviour that > triggers the bug. > > Fabien, any chance to either bisect or get a bit more information on the > backtrace? There is a promising "keep_error_builds" option in buildfarm settings, but it does not seem to be used anywhere in the scripts. Well, I can probably relaunch by hand. However, given the experimental nature of the setup, I think that the most probable cause is a newly introduced gcc bug, so I'd suggest to wait to check whether the issue persist before spending time on that, and if it persists to investigate further to either report a bug to gcc or pg, depending. Also, I'll recompile gcc before the next weekly builds. -- Fabien.
В списке pgsql-hackers по дате отправления: