8.0.0 make check fails on Solaris 9 (sparc)

On Thu, Jan 27, 2005 at 11:06:54AM -0500, Tamas Vincze wrote:

I see test failures in float4, float8 and misc.

What configure options did you use? What compiler are you using?
Did you specify any custom compiler or linker options?

I've built PostgreSQL 8.0.0 (from CVS) on Solaris 9/sparc many times
with gcc 3.4.2 and all "make check" tests pass.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Hi Michael,

I see test failures in float4, float8 and misc.

What configure options did you use? What compiler are you using?
Did you specify any custom compiler or linker options?

The configure command was:
$ ./configure --prefix=/usr/local/pgsql-8.0.0 --enable-thread-safety
--with-includes=/export/home/vincze/include
--with-libs=/export/home/vincze/lib

The readline library is installed under my home, that's why the
--with-includes/libs are there.

I have gcc 2.96 and haven't specified any custom options to it or
to the linker.

I've built PostgreSQL 8.0.0 (from CVS) on Solaris 9/sparc many times
with gcc 3.4.2 and all "make check" tests pass.

I've compiled from the final tarball - maybe something's changed
since you got the sources from CVS?

Tamas

On Thu, Jan 27, 2005 at 02:08:36PM -0500, Tamas Vincze wrote:

The configure command was:
$ ./configure --prefix=/usr/local/pgsql-8.0.0 --enable-thread-safety
--with-includes=/export/home/vincze/include
--with-libs=/export/home/vincze/lib

The readline library is installed under my home, that's why the
--with-includes/libs are there.

Is anything else under there? Aside from enabling various server-side
languages and SSL, the only thing I see different between my configure
and yours is that you use --enable-thread-safety and I don't, and
I use --enable-debug and you don't. When I get a chance I'll do a
build with --enable-thread-safety and without --enable-debug and
see if it matters.

I have gcc 2.96 and haven't specified any custom options to it or
to the linker.

Have you tried gcc 3.x? I don't know if it matters, but that's
another difference between our builds.

I've built PostgreSQL 8.0.0 (from CVS) on Solaris 9/sparc many times
with gcc 3.4.2 and all "make check" tests pass.

I've compiled from the final tarball - maybe something's changed
since you got the sources from CVS?

I've been following the 8.0 development for months, doing CVS updates
and rebuilding almost daily, include once earlier this morning. I
don't remember seeing any "make check" failures recently.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr <mike@fuhr.org> writes:

On Thu, Jan 27, 2005 at 02:08:36PM -0500, Tamas Vincze wrote:

I've compiled from the final tarball - maybe something's changed
since you got the sources from CVS?

I've been following the 8.0 development for months, doing CVS updates
and rebuilding almost daily, include once earlier this morning. I
don't remember seeing any "make check" failures recently.

There are two different Solaris 9 machines in the build farm, too.
http://www.pgbuildfarm.org/cgi-bin/show_status.pl

regards, tom lane

On Thu, Jan 27, 2005 at 12:59:06PM -0700, Michael Fuhr wrote:

When I get a chance I'll do a build with --enable-thread-safety
and without --enable-debug and see if it matters.

It occurred to me that --enable-thread-safety affects the client-side
libraries so I don't know why that would matter to the server, but
I did another build anyway and all checks passed (see below).

A few months ago an issue with strtod() on Solaris came up:

http://archives.postgresql.org/pgsql-bugs/2004-08/msg00073.php
http://archives.postgresql.org/pgsql-bugs/2004-08/msg00127.php

I wonder if you're experiencing a related or similar problem that
only shows up with certain build tools.

Build results:

% ./configure --enable-thread-safety && gmake check
...
======================
All 96 tests passed.
======================

% ldd src/test/regress/tmp_check/install/usr/local/pgsql/bin/postmaster
libz.so.1 => /usr/lib/libz.so.1
libreadline.so.5 => /usr/local/lib/libreadline.so.5
libcurses.so.1 => /usr/lib/libcurses.so.1
librt.so.1 => /usr/lib/librt.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libgen.so.1 => /usr/lib/libgen.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1
/usr/platform/SUNW,Ultra-1/lib/libmd5_psr.so.1

% gcc --version
gcc (GCC) 3.4.2
...

% gmake --version
GNU Make 3.80
...

% uname -a
SunOS foo.example.com 5.9 Generic_117171-17 sun4u sparc SUNW,Ultra-1

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr wrote:

Is anything else under there?

I re-built it with

$ ./configure --prefix=/usr/local/pgsql-8.0.0 --without-readline

and still have the same errors in the float4, float8 and misc tests.

ldd src/test/regress/tmp_check/install/usr/local/pgsql-8.0.0/bin/postmaster
libz.so => /usr/lib/libz.so.1
librt.so.1 => /usr/lib/librt.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libgen.so.1 => /usr/lib/libgen.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
libmp.so.2 => /usr/lib/libmp.so.2
/usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/libmd5_psr.so.1

% uname -a
SunOS testhost 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Blade-1000

Have you tried gcc 3.x?

No, not yet. I have a pretty old make too: GNU Make version 3.78.1
but I think it's unlikely that it would cause such errors.
But I guess my only option now is to upgrade my build tools and give
it another try...

Tamas

On Thu, Jan 27, 2005 at 02:33:05PM -0700, Michael Fuhr wrote:

A few months ago an issue with strtod() on Solaris came up:

http://archives.postgresql.org/pgsql-bugs/2004-08/msg00073.php
http://archives.postgresql.org/pgsql-bugs/2004-08/msg00127.php

I wonder if you're experiencing a related or similar problem that
only shows up with certain build tools.

The errors were the following:

template1=# SELECT 'NaN'::float4;
ERROR: 22003: type "real" value out of range: overflow
LOCATION: CheckFloat4Val, float.c:219

The code around float.c:219 looks like this:

if (fabs(val) > FLOAT4_MAX)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("type \"real\" value out of range: overflow")));

I wonder what a debugging printf() would show for val, fabs(val),
and FLOAT4_MAX here.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

On Thu, Jan 27, 2005 at 05:11:16PM -0500, Tamas Vincze wrote:

But I guess my only option now is to upgrade my build tools and give
it another try...

Even if that works, it might be useful to track down exactly what's
causing the problem.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael, Fuhr wrote:

The errors were the following:

template1=# SELECT 'NaN'::float4;
ERROR: 22003: type "real" value out of range: overflow
LOCATION: CheckFloat4Val, float.c:219

The code around float.c:219 looks like this:

if (fabs(val) > FLOAT4_MAX)
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("type \"real\" value out of range: overflow")));

I wonder what a debugging printf() would show for val, fabs(val),
and FLOAT4_MAX here.

Here it is:
val: NaN
fabs(val): NaN
FLOAT4_MAX: 340282346638528859811704183484516925440.000000

It must be a compiler bug in gcc 2.96 because I had an older
one (2.95.3) from the SFWgcc package installed under /opt/sfw
and using that all test results were OK.
I installed the new gcc 3.4.2 and that worked too.

Tamas