PG Bug reporting form <noreply@postgresql.org> writes:
> (gdb) bt
> #0 0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>,
> __dest=<optimized out>) at
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> #1 AppendJumble (item=<optimized out>, item@entry=0x7f403929afd8 "u",
> size=30595144541, size@entry=4, jstate=<optimized out>, jstate=<optimized
> out>) at ./build/../src/backend/utils/misc/queryjumble.c:213
If we take that at face value --- which isn't a very safe assumption when
dealing with optimized code --- it suggests that the loop in AppendJumble
has gone crazy and allowed "size" to wrap around to some large value.
If that happened then it'd iterate until "item" advances off the end of
memory and you get SIGSEGV.
I don't see how that could possibly happen though, short of a compiler
bug:
while (size > 0)
{
Size part_size;
...
part_size = Min(size, JUMBLE_SIZE - jumble_len);
...
size -= part_size;
}
How could the value of part_size exceed size?
I've spent time staring at that code before, because Coverity regularly
whines about queryjumble.c in terms suggesting that it sees a potential
for exactly this kind of bug. But I sure don't see it.
regards, tom lane