Rafael Martinez Guerrero <r.m.guerrero@usit.uio.no> writes:
> * Information from CORE dump we got with --enable-debug. We have
> compiled a new version of postgres and run it through gdb with the core
> dump we had/got from postgres without --enable-debug.=20
Okay, theoretically that works, but it might be smarter to install the
debug build and get a fresh core dump that definitely corresponds to it.
> #0 0xb734d07c in memcpy () from /lib/tls/libc.so.6
> #1 0x0806bba8 in DataFill (data=3D0xb7489000 <Address 0xb7489000 out of
> bounds>, tupleDesc=3D0x82fd554, value=3D0x82fd550, nulls=3D0xbfff7ec0 " n =
> ",
> infomask=3D0x836e904c, bit=3D0x836e904f "\003\f") at heaptuple.c:139
If accurate, that says it's crashing here:
/* fixed-length pass-by-reference */
Assert(att[i]->attlen > 0);
data_length = att[i]->attlen;
--> memcpy(data, DatumGetPointer(value[i]), data_length);
which suggests either that att[i]->attlen is corrupt, or that the
computed length for the preceding column was wacko (leading to the
data pointer being moved to a silly address), or that the provided
value[i] is wrong. In the context at hand none of these seem especially
likely, but one of them must be the case. Can you look with jdb to
see what the value of i is, and print out the contents of the *(att[i])
struct? Also look at "data" and "value[i]" to see if they are sensible
pointers or not.
How reproducible is the crash --- does it happen every time you execute
this particular FETCH?
regards, tom lane
