[BUGS] Integer parsing bug?
Section 8.1 of the manual gives the range of an integer as -2147483648 to +2147483647. template1=# select '-2147483648'::int; int4 - -2147483648 (1 row) template1=# select -2147483648::int; ERROR: integer out of range Oops. template1=# select version(); version - PostgreSQL 7.4.1 on i686-pc-linux-gnu, compiled by GCC 2.96 (1 row) Completely vanilla build - no options other than --prefix to configure. Clean installation, this is immediately after an initdb. I see the same bug on Solaris, built with Forte C in 64 bit mode. Cheers, Steve ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Integer parsing bug?
On Wed, Mar 03, 2004 at 12:31:47PM -0500, Bruce Momjian wrote: > Yep, it definately looks weird: > > test=> select '-2147483648'::int; > int4 > - >-2147483648 > (1 row) > > test=> select -2147483648::int; > ERROR: integer out of range > test=> select -2147483647::int; > ?column? > - >-2147483647 > (1 row) > > test=> select '-2147483649'::int; > ERROR: value "-2147483649" is out of range for type integer > > The non-quoting works only for *47, and the quoting works for *48, but > both fail for *49. > > I looked at libc's strtol(), and that works fine, as does our existing > parser checks. The error is coming from int84, a comparison function > called from the executor. Here is a test program: I traced through that far and managed to convince myself that the problem was that it was considering a -...48 to be an int8, rather than an int4, so was hitting int84() when it shouldn't have been - and the input values for int84() looked very, very broken. Specifically, a breakpoint on int84() fires on -..48 and -..49, but not on -..47, suggesting that the problem is somewhere in the parsing before it reaches int84(). I'm happy to take a look at it, but got very lost in the maze of twisty parse routines, all alike, when I tried to track back further. Is there any overview documentation on that end of the code? > I see in the freebsd machine/limits.h file: > > * According to ANSI (section 2.2.4.2), the values below must be usable by > * #if preprocessing directives. Additionally, the expression must have the > * same type as would an expression that is an object of the corresponding > * type converted according to the integral promotions. The subtraction for > * INT_MIN, etc., is so the value is not unsigned; e.g., 0x8000 is an > * unsigned int for 32-bit two's complement ANSI compilers (section 3.1.3.2). > * These numbers are for the default configuration of gcc. They work for > * some other compilers as well, but this should not be depended on. > > #define INT_MAX 0x7fff /* max value for an int */ > #define INT_MIN (-0x7fff - 1) /* min value for an int */ > > Basically, what is happening is that the special value -INT_MAX-1 is > being converted to an int value, and the compiler is casting it to an > unsigned. Seems this is a known C issue and I can't see a good fix for > it except perhaps check for INT_MIN int he int84 function, but I ran > some tests and that didn't work either. I don't read it that way. INT_MIN is correctly read as a signed int, but it can't be defined as -0x800 as that would be parsed as -(0x8000) and the constant 0x8000 is unsigned. Cheers, Steve ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Integer parsing bug?
On Wed, Mar 03, 2004 at 06:27:07PM -0500, Tom Lane wrote: > Steve Atkins <[EMAIL PROTECTED]> writes: > >> test=> select -2147483648::int; > >> ERROR: integer out of range > > There is no bug here. You are mistakenly assuming that the above > represents > select (-2147483648)::int; > But actually the :: operator binds more tightly than unary minus, > so Postgres reads it as > select -(2147483648::int); > and quite rightly fails to convert the int8 literal to int. > > If you write it with the correct parenthesization it works: > > regression=# select -2147483648::int; > ERROR: integer out of range > regression=# select (-2147483648)::int; OK... That makes sense if the parser has no support for negative constants, but it doesn't seem like intuitive behaviour. BTW, the original issue that led to this was: db=>CREATE function t(integer) RETURNS integer AS ' BEGIN return 0; END; ' LANGUAGE 'plpgsql'; db=> select t(-2147483648); ERROR: function t(bigint) does not exist Which again makes sense considering the way the parser works, but still seems to violate the principle of least surprise. Cheers, Steve ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] 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: st...@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" works as expected. Entering "\d pa" 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: 0x, 0x 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 0x7fff874543d6 __kill + 10 1 libSystem.B.dylib 0x7fff874f4972 abort + 83 2 libSystem.B.dylib 0x7fff8740c615 free + 128 3 libedit.2.dylib 0x0001000899a8 fn_complete + 659 4 libedit.2.dylib 0x00010008f416 rl_complete + 182 5 libedit.2.dylib 0x00010008f428 rl_complete + 200 6 libedit.2.dylib 0x00010008db87 el_gets + 709 7 libedit.2.dylib 0x00010008f9bf readline + 279 8 psql0x000187cf gets_interactive + 79 9 psql0x0001c22b MainLoop + 539 10 psql0x0001e924 main + 2964 11 psql0x00011524 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x rbx: 0x0002 rcx: 0x7fff5fbfeeb8 rdx: 0x rdi: 0x98d7 rsi: 0x0006 rbp: 0x7fff5fbfeed0 rsp: 0x7fff5fbfeeb8 r8: 0x0e03 r9: 0x r10: 0x7fff87450412 r11: 0x0202 r12: 0x0001000cf000 r13: 0x0001000cd000 r14: 0x r15: 0x0001 rip: 0x7fff874543d6 rfl: 0x0202 cr2: 0x0001000ed000 Binary Images: 0x1 -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) /usr/lib/libedit.2.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) /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) /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 0x7fe0 - 0x7fe01fff libSystem.B.dylib ??? (???) <95E02DD0-ADEA-745B-E7FA-ABA064E4658C> /usr/lib/libSystem.B.dylib -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5589: psql dies with bad free() in libedit
On Aug 1, 2010, at 10:11 PM, Tom Lane wrote: > "Steve Atkins" 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" works as expected. Entering "\d pa" >> 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
