BUG #5589: psql dies with bad free() in libedit
The following bug has been logged online:
Bug reference: 5589
Logged by: Steve Atkins
Email address: steve@blighty.com
PostgreSQL version: 9.0beta3
Operating system: OS X
Description: psql dies with bad free() in libedit
Details:
I have a database that contains two tables (partminer and partminer2), and
two sequences (partminer2_id_seq and partminer_pk), on a 9.0beta3
installation built from source with default configure options.
The database was corrupted (cable for an external drive fell out), but
apparently recovered fine on restart.
From psql, entering "\d p<tab>" works as expected. Entering "\d pa<tab>"
throws an abort from malloc(): "malloc: *** error for object 0x3: pointer
being freed was not allocated", with the error within libedit.
Process: psql [39127]
Path: /Volumes/G-RAID/pgsql/bin/psql
Identifier: psql
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: bash [38218]
Date/Time: 2010-08-01 21:12:06.523 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 187973 sec
Crashes Since Last Report: 12
Per-App Crashes Since Last Report: 11
Anonymous UUID: 1FE5E5C3-10D8-4225-B3F2-7AD2A0E5B4A3
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
abort() called
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff874543d6 __kill + 10
1 libSystem.B.dylib 0x00007fff874f4972 abort + 83
2 libSystem.B.dylib 0x00007fff8740c615 free + 128
3 libedit.2.dylib 0x00000001000899a8 fn_complete + 659
4 libedit.2.dylib 0x000000010008f416 rl_complete + 182
5 libedit.2.dylib 0x000000010008f428 rl_complete + 200
6 libedit.2.dylib 0x000000010008db87 el_gets + 709
7 libedit.2.dylib 0x000000010008f9bf readline + 279
8 psql 0x00000001000087cf gets_interactive + 79
9 psql 0x000000010000c22b MainLoop + 539
10 psql 0x000000010000e924 main + 2964
11 psql 0x0000000100001524 start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000002 rcx: 0x00007fff5fbfeeb8
rdx: 0x0000000000000000
rdi: 0x00000000000098d7 rsi: 0x0000000000000006 rbp: 0x00007fff5fbfeed0
rsp: 0x00007fff5fbfeeb8
r8: 0x0000000000000e03 r9: 0x0000000000000000 r10: 0x00007fff87450412
r11: 0x0000000000000202
r12: 0x00000001000cf000 r13: 0x00000001000cd000 r14: 0x0000000000000000
r15: 0x0000000000000001
rip: 0x00007fff874543d6 rfl: 0x0000000000000202 cr2: 0x00000001000ed000
Binary Images:
0x100000000 - 0x100051ff7 +psql ??? (???)
<9D94BB44-2BF0-1B3E-6CC9-2BA515E0606D> /Volumes/G-RAID/pgsql/bin/psql
0x100062000 - 0x10007dff7 +libpq.5.dylib 5.3.0 (compatibility
5.0.0) <12AF8A1A-F17B-4A97-32E6-FD7EB8008A59>
/Volumes/G-RAID/pgsql/lib/libpq.5.dylib
0x100085000 - 0x1000a1fe7 libedit.2.dylib 2.11.0
(compatibility 2.0.0) <EAF4D57B-1ADC-06CF-DAC7-72AF835140FD>
/usr/lib/libedit.2.dylib
0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???)
<B536F2F1-9DF1-3B6C-1C2C-9075EA219A06> /usr/lib/dyld
0x7fff82551000 - 0x7fff82555ff7 libmathCommon.A.dylib 315.0.0
(compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5>
/usr/lib/system/libmathCommon.A.dylib
0x7fff82b78000 - 0x7fff82bb7fef libncurses.5.4.dylib 5.4.0
(compatibility 5.4.0) <E1F34D53-3D62-78C0-CAD8-8AD22C110A9E>
/usr/lib/libncurses.5.4.dylib
0x7fff87405000 - 0x7fff875c5fef libSystem.B.dylib 125.2.0
(compatibility 1.0.0) <95E02DD0-ADEA-745B-E7FA-ABA064E4658C>
/usr/lib/libSystem.B.dylib
0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???)
<95E02DD0-ADEA-745B-E7FA-ABA064E4658C> /usr/lib/libSystem.B.dylib
"Steve Atkins" <steve@blighty.com> writes:
I have a database that contains two tables (partminer and partminer2), and
two sequences (partminer2_id_seq and partminer_pk), on a 9.0beta3
installation built from source with default configure options.
From psql, entering "\d p<tab>" works as expected. Entering "\d pa<tab>"
throws an abort from malloc(): "malloc: *** error for object 0x3: pointer
being freed was not allocated", with the error within libedit.
This sounds a lot like a known bug in Apple's version of libedit:
http://archives.postgresql.org/pgsql-bugs/2010-04/msg00127.php
libedit has proven pretty buggy over the years, and Apple isn't too
speedy to fix it. The best bet really is to use GNU readline instead.
regards, tom lane
On Aug 1, 2010, at 10:11 PM, Tom Lane wrote:
"Steve Atkins" <steve@blighty.com> writes:
I have a database that contains two tables (partminer and partminer2), and
two sequences (partminer2_id_seq and partminer_pk), on a 9.0beta3
installation built from source with default configure options.
From psql, entering "\d p<tab>" works as expected. Entering "\d pa<tab>"
throws an abort from malloc(): "malloc: *** error for object 0x3: pointer
being freed was not allocated", with the error within libedit.This sounds a lot like a known bug in Apple's version of libedit:
http://archives.postgresql.org/pgsql-bugs/2010-04/msg00127.php
Ew. Yes it does.
libedit has proven pretty buggy over the years, and Apple isn't too
speedy to fix it. The best bet really is to use GNU readline instead.
Yup.
Cheers,
Steve