I wrote:
> "Francisco Reyes" <lists@stringsutils.com> writes:
>> On 3:09 pm 05/28/08 Gregory Stark <stark@enterprisedb.com> wrote:
> Does it really have a COPY command at the beginning? Are you really doing >\i data/usb_t_60M.sql or were you trying
todo a copy from this file?
>> Argh..That's it.
>> When I re-organized the scripts I must have taken the copy command from the top of the data file and did not put a
'copyfrom' in the calling script.
> Hmm ... even so, it shouldn't have crashed, it should at worst have
> given you an out-of-memory error message.
Hmm, I see the problem: the pqexpbuffer code maxes out at INT_MAX bytes
in the string buffer, which would be all right except that it has no
good way to report the error and so the input is just getting truncated
at that length. But then what happens is that pqPuts computes
strlen(s) + 1, which is still all right because size_t is 64 bits
on this machine, and passes that to pqPutMsgBytes, which computes
conn->outMsgEnd + len *and smashes that to int*. So the value passed
to pqCheckOutBufferSpace is negative, and the latter falsely concludes
there's enough space in the buffer, and then the memcpy goes boom.
A minimum solution would be to make pqCheckOutBufferSpace deal in
size_t not int, but I have a feeling there are a lot of other similar
gotchas when running this code on a 64-bit machine. We use int
arithmetic an awful lot for stuff that probably should be size_t
or ssize_t ...
regards, tom lane
