Re: gs_group_1 crashing on 13beta2/s390x
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Christoph Berg <myon@debian.org>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-07-16T15:08:32Z
Lists: pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> It's hardly surprising that datumCopy would segfault when given a > Tom> null "value" and told it is pass-by-reference. However, to get to > Tom> the datumCopy call, we must have passed the MemoryContextContains > Tom> check on that very same pointer value, and that would surely have > Tom> segfaulted as well, one would think. > Nope, because MemoryContextContains just returns "false" if passed a > NULL pointer. Ah, right. So you could imagine getting here if the finalfn had returned PointerGetDatum(NULL) with isnull = false. We have some aggregate transfns that are capable of doing that for internal-type transvalues, I think, but the finalfn never should do it. In any case we still have the fact that this isn't being seen in our buildfarm; and that's not for lack of s390 machines. So I still think the most likely explanation is a compiler bug in bleeding-edge gcc. Probably what Christoph should be trying to figure out is why he can't reproduce it manually. There must be some discrepancy between his environment and the build machines; but what? regards, tom lane
Commits
-
llvmjit: Work around bug in LLVM 3.9 causing crashes after 72559438f92.
- c835c7ffe21d 12.5 landed
- 4a4f4487d2d2 11.10 landed
- fe2a16d8b3e6 14.0 landed
- efc9a8e9800c 13.1 landed
-
llvmjit: Also copy parameter / return value attributes from template functions.
- f3dee5b9aba6 11.10 landed
- c8a2bb0f1abf 12.5 landed
- ae3e75abab22 13.1 landed
- 72559438f92f 14.0 landed