Re: [HACKERS] Strange pgsql crash on MacOSX
I wrote: > The source code available from Apple shows that they got this code from > NetBSD originally > /*$NetBSD: history.c,v 1.25 2003/10/18 23:48:42 christos Exp $*/ > so this may well be a pretty generic *BSD bug. Anyone clear on who to > report it to? I have no idea if libedit is an independent project... Some digging in the NetBSD CVS shows that they found both parts of this bug more than two years ago: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/history.c.diff?r1=1.25&r2=1.27&f=h so the short and sweet answer is that Apple is behind the times. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Strange pgsql crash on MacOSX
Shane Ambler <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hm, so the question is: is it our bug or Apple's? If you kept the
>> busted history file, would you be willing to send me a copy?
> The zip file attached has the psql_history file that crashes when
> quiting but doesn't appear to contain the steps I done when it first
> crashed.
So the answer is: it's Apple's bug, or at least not ours. libedit
contains a typo that causes it to potentially fail when saving strings
exceeding 256 bytes. Check out this code (around line 730 in history.c):
len = strlen(ev.str) * 4;
if (len >= max_size) {
char *nptr;
max_size = (len + 1023) & 1023;
nptr = h_realloc(ptr, max_size);
I think the intent of the max_size recalculation is to select the next
1K boundary larger than "len", but it actually produces a number *less*
than 1K. Probably "(len + 1023) & ~1023" was meant ... but even that
is wrong if len is exactly a multiple of 1024, because it will fail to
round up. So the buffer is realloc'd too small, and that results in
a potential memory clobber if the history entry is less than 1K, and a
guaranteed clobber if it's more.
The source code available from Apple shows that they got this code from
NetBSD originally
/* $NetBSD: history.c,v 1.25 2003/10/18 23:48:42 christos Exp $*/
so this may well be a pretty generic *BSD bug. Anyone clear on who to
report it to? I have no idea if libedit is an independent project...
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Strange pgsql crash on MacOSX
Shane Ambler <[EMAIL PROTECTED]> writes: > I just found out the problem. > psql_history - I had tried to copy from a text file earlier that was > utf8 and came up with some errors, I guess these got into the history > file and stuffed it up. Hm, so the question is: is it our bug or Apple's? If you kept the busted history file, would you be willing to send me a copy? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Strange pgsql crash on MacOSX
Shane Ambler wrote: Tom Lane wrote: Shane Ambler <[EMAIL PROTECTED]> writes: postgres=# \q psql(24931) malloc: *** error for object 0x180a800: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug psql(24931) malloc: *** set a breakpoint in szone_error to debug Segmentation fault I think we've seen something like this before in connection with readline/libedit follies. Does the crash go away if you invoke psql with "-n" option? If so, exactly which version of readline or libedit are you using? psql -n stops the error. I just found out the problem. psql_history - I had tried to copy from a text file earlier that was utf8 and came up with some errors, I guess these got into the history file and stuffed it up. Renamed it so it created a new one and all is fine now. -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Strange pgsql crash on MacOSX
Shane Ambler <[EMAIL PROTECTED]> writes: > postgres=# \q > psql(24931) malloc: *** error for object 0x180a800: incorrect checksum > for freed object - object was probably modified after being freed, break > at szone_error to debug > psql(24931) malloc: *** set a breakpoint in szone_error to debug > Segmentation fault I think we've seen something like this before in connection with readline/libedit follies. Does the crash go away if you invoke psql with "-n" option? If so, exactly which version of readline or libedit are you using? FWIW, I do not see this on a fully up-to-date 10.4.8 G4 laptop. I see $ ls -l /usr/lib/libedit* -rwxr-xr-x 1 root wheel 112404 Sep 29 20:59 /usr/lib/libedit.2.dylib lrwxr-xr-x 1 root wheel 15 Apr 26 2006 /usr/lib/libedit.dylib -> libedit.2.dylib $ so it seems that Apple did update libedit not too long ago ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
