Thread: Re: Re: Better backtrace (wasRe: pqReadData() -- backend closed the ch
Well, the bottom line seems to be that there's something broken about the floating-point support on that box. Look in /usr/local/pgsql/data/tmp --- I made a trivial test program that just tries to convert a short integer to a double. I get: > cat tryit.c #include <stdio.h> #include <stdlib.h> int main() { short i = 22; double d; d = i; printf("i = %d, d = %g\n", i, d); return 0; } > gcc tryit.c > ./a.out Illegal instruction (core dumped) > gcc -msoft-float tryit.c > ./a.out i = 22, d = 22 > uname -a FreeBSD jc12.easthighschool.net 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC i386 > gcc -v Using builtin specs. gcc version 2.95.3 [FreeBSD] 20010315 (release) > I speculate that your box is so old that it has no hardware floating point at all, and that what we are seeing here is a fault in FreeBSD's software emulation of the 'fild' (short-to-double) instruction. Or maybe it's an assembly-time problem. A google search turned up http://gatekeeper.dec.com/pub/BSD/FreeBSD/FreeBSD-current/src/contrib/binutils/include/opcode/ChangeLog with the following interesting entry: 2000-05-17 Maciej W. Rozycki <macro@ds2.pg.gda.pl> * i386.h: Use sl_FP, not sl_Suf for fild. which suggests that older versions of the GNU toolchain may mis-assemble 'fild' instructions. It'd be worth asking around in BSD-specific mailing lists to see if this is a known problem; I didn't find anything else in my web search, but I wasn't trying very hard. I think Postgres is off the hook, in any case. regards, tom lane
Re: Better backtrace (wasRe: pqReadData() -- backend closed the ch
From
missive@frontiernet.net (Lee Harr)
Date:
On Wed, 1 Aug 2001 16:07:59 +0000 (UTC), Tom Lane <tgl@sss.pgh.pa.us> wrote: > Well, the bottom line seems to be that there's something broken about > the floating-point support on that box. Look in >> uname -a > FreeBSD jc12.easthighschool.net 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001 jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC i386 >> gcc -v > Using builtin specs. > gcc version 2.95.3 [FreeBSD] 20010315 (release) > > I speculate that your box is so old that it has no hardware floating > point at all, and that what we are seeing here is a fault in FreeBSD's > software emulation of the 'fild' (short-to-double) instruction. Or > maybe it's an assembly-time problem. A google search turned up > > http://gatekeeper.dec.com/pub/BSD/FreeBSD/FreeBSD-current/src/contrib/binutils/include/opcode/ChangeLog > > which suggests that older versions of the GNU toolchain may mis-assemble > 'fild' instructions. > > It'd be worth asking around in BSD-specific mailing lists to see if this > is a known problem; I didn't find anything else in my web search, but I > wasn't trying very hard. I think Postgres is off the hook, in any case. > > regards, tom lane I recompiled the kernel replacing options MATH_EMULATE with options GPL_MATH_EMULATE and I am now able to access the database normally. As an experiment, I had another 486SX (no hardware fpu) which showed the exact same problem when I transplanted the hard drive. So it looks like this may be a problem which will show up on the older 486 machines, but can be worked around by recompiling the kernel with the alternate math emulation code. I sent a report of your findings to one of the freebsd mailing lists. Thanks again, Tom.