Re: segfault in geqo on experimental gcc animal - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: segfault in geqo on experimental gcc animal
Date
Msg-id alpine.DEB.2.21.1911131517290.13316@lancre
Whole thread Raw
In response to Re: segfault in geqo on experimental gcc animal  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: segfault in geqo on experimental gcc animal  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
>> 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.

I did some manual testing.

All versions are tested failed miserably (I tested master, 12, 11, 10, 
9.6…). High probability that it is a newly introduced gcc bug, however pg 
is not a nice self contain tested case to submit to gcc for debugging:-(

I suggest to ignore for the time being, and if the problem persist I'll 
try to investigate to detect which gcc commit caused the regression.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: checking my understanding of TupleDesc
Next
From: Pavel Stehule
Date:
Subject: Re: dropdb --force