Re: BUG #5418: psql exits after using tab-completion with error message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: 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-13 21:02:54
Message-ID: 10385.1271192574@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
>> prices=# \d abapsql(11407) malloc: *** error for object 0xe: pointer being
>> freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>> Abort trap

> This could be a bug in psql, a buggy/damaged readline library, etc.
> ...
> I don't have access to Mac OS X 10.6, but maybe someone else here does
> and can reproduce the issue.

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>".

Stack trace looks like this:

regression=# \d tenpsql(16771) malloc: *** error for object 0xd: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff83652886 in __kill ()
(gdb) bt
#0 0x00007fff83652886 in __kill ()
#1 0x00007fff836f2eae in abort ()
#2 0x00007fff8360aa75 in free ()
#3 0x000000010009b9a8 in fn_complete ()
#4 0x00000001000a1416 in rl_complete ()
#5 0x00000001000a1428 in rl_complete ()
#6 0x000000010009fb87 in el_gets ()
#7 0x00000001000a19bf in readline ()
#8 0x00000001000083ff in gets_interactive (prompt=<value temporarily unavailable, due to optimizations>) at input.c:76
#9 0x000000010000bfdb in MainLoop (source=0x7fff705a30c0) at mainloop.c:134
#10 0x000000010000e6d4 in main (argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff5fbff510) at startup.c:305

The object address is nonreproducible (varies even in seemingly
identical test runs), but it's always a very small integer, 1 to 0xd or
so.

Since this doesn't happen on any of my libreadline-using boxes, it seems
like a fairly safe bet that it's a bug in libedit, rather than us using
the library incorrectly. You can try to get Apple to take an interest,
but there's not much we can do about it.

I concur with Alvaro's suggestion to install GNU readline instead of
depending on libedit.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Cris Pond 2010-04-13 22:08:43 BUG #5419: Default parameters in PLPGSQL functions skipping every other value in pgAdmin view
Previous Message Rusty Conover 2010-04-13 20:38:39 Re: BUG #5412: Crash in production SIGSEGV, equalTupleDescs (tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at tupdesc.c