From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Ben Madin <ben(at)ausvet(dot)com(dot)au>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5418: psql exits after using tab-completion with error message |
Date: | 2010-04-15 04:13:51 |
Message-ID: | 22441.1271304831@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> It's fairly easy to reproduce in the regression database:
> type "\d ten<TAB>". I'm not sure what the triggering condition
> is exactly, because some seemingly-similar cases don't fail,
> for instance "\d test<TAB>" works as expected, ditto "\d t<TAB>".
It turns out that the problem occurs when there are exactly 9 + 10*N
possible completions, for any N>=0. There's an off-by-one logic bug
in libedit that results in a memory stomp because it forgets to enlarge
an array before storing a terminating null pointer in it.
The upstream netbsd sources incorporated a fix some time ago:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.82&r2=1.83&sortby=date&f=h
with credit to Caleb Welton at Greenplum --- I wonder if he found it
because of psql failing? Apple hasn't incorporated this fix as of
OS X 10.6.3, however.
What's slightly more distressing is that the same source file
(readline.c) appears to have at least two other occurrences of the same
broken array-enlargement coding pattern, which were *not* fixed.
I've reported this to Apple but I'm not real sure where to file NetBSD
bugs. Anybody want to yank the BSD guys' chain about the other errors?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-04-15 05:58:41 | Re: Bug in CREATE FUNCTION with character type (CONFIRMED BUG) |
Previous Message | Bruce Momjian | 2010-04-15 02:58:00 | Re: BUG #5420: pg_attribute broken |