Re: Psql crashes with Segmentation fault on copy from

Tom Lane wrote:
> I wrote:
> > "Francisco Reyes" <lists(at)stringsutils(dot)com> writes:
> >> On 3:09 pm 05/28/08 Gregory Stark <stark(at)enterprisedb(dot)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 to do 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 'copy from' 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 ...

I assume this is not a TODO item.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +