Skip site navigation (1) Skip section navigation (2)

Re: INSERT causes psql to crash

From: jao(at)geophile(dot)com
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: INSERT causes psql to crash
Date: 2006-01-26 22:47:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
I was experiencing a psql crash. psql reported "buffer overflow detected"
and a stack dump.

Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> jao(at)geophile(dot)com writes:
>> Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> If it just started happening, I'd speculate about a corrupt executable
>>> file for psql or libpq.  I doubt it's got anything to do with the server
>>> side.
> ...
> In any case, the next step is to get more debugging data ... please
> see about that debug-enabled rebuild.  If you really want to pursue
> the server-bug theory first, you might try dumping the data passed
> across the connection with strace or ethereal or similar tools
> to see if there's any differences.

I loaded the symbols from a debug-enabled build but have been unable
to get a more informative stack dump.

I'm hoping strace output will be useful. To recap, psql crashes
on "INSERT INTO TEST VALUES(8)". The insert succeeds, and strace
shows the insert response coming back. I'm wondering if there is
anything suspicious in the response from the backend:

recv(3, "C\0\0\0\30INSERT 1188218874 1\0Z\0\0\0\5I", 16384, 0) = 31
open("/dev/tty", O_RDWR|O_NONBLOCK|O_NOCTTY) = 4
writev(4, [{"*** buffer overflow detected ***"..., 34}, {"psql", 4}, {" 
terminated\n", 12}], 3*** buffer overflow detected ***: psql terminated

Jack Orenstein

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2006-01-26 22:53:26
Subject: Re: INSERT causes psql to crash
Previous:From: Bruce MomjianDate: 2006-01-26 22:42:27
Subject: Re: improper estimates even with high statistic values

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group