postgresql bug report (fwd)

To compile postgres using gcc 2.7.2.1 I had to modify 2 files

src/interfaces/libpq++/pgconnection.cc
src/interfaces/libpq++/pgenv.h

Particularly,
#include <iostream> to #include <iostream.h>
in src/interfaces/libpq++/pgenv.h
and
#include <strstream> to #include <strstream.h>

There are no problem with egcs 1.12 release
Could somebody made changes in cvs sources.

Oleg

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

The Hermit Hacker <scrappy@hub.org> writes:

it seems that this problem is a type casting/promotion bug in the
source. The
routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
int2eq() in
backend/utils/adt/int.c via a function pointer
*fmgr_faddr(&key[0].sk_func). As
the type information for int2eq is lost via the function pointer,
the compiler
passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
int16's.
This particular bug goes away, if I for example change int2eq to:

bool
int2eq(int32 arg1, int32 arg2)
{
return (int16)arg1 == (int16)arg2;
}

Yow. I can't believe that we haven't seen this failure before on a
variety of platforms. Calling an ANSI-style function that has char or
short args is undefined behavior if you call it without benefit of a
prototype, because the parameter layout is allowed to be different.
Apparently, fewer compilers exploit that freedom than I would've thought.

Really, *all* of the builtin-function routines ought to take arguments
of type Datum and then do the appropriate Get() macro to extract what
they want from 'em. That's a depressingly large amount of work, but
at the very least the functions that take bool and int16 have to be
changed...

regards, tom lane

Marc,
In porting the RedHat 6.0 srpm set for a linuxppc release we
believe a bug has been identified in
the postgresql source for 6.5-0.beta1. Our development tools are as
follows...

glibc 2.1.1 pre 2
linux 2.2.6
egcs 1.1.2
the latest binutils snapshot

The bug that we see is that when egcs compiles postgresql at -O1 or
higher (-O0 is fine),
postgresql creates incorrectly formed databases such that when the user
does a destroydb
the database can not be destroyed. Franz Sirl has identified the problem
as follows...

[snip]

I've been using PosgreSQL and LinuxPPC for a longtime, and never seen
these kind of problems (I have a serious problem with 2.1.xxx kernels
whenever I try to run PostgreSQL, but this is a different story,
anyway).

I have a standard installation using the R4.2 CD from LinuxPPC org.

kernel 2.1.24
glibc-0.961212-1h
gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)
binutils-2.9.1-1a

However your explnation sounds reasonable, I will look into to see why
my system seems to have no problem.
---
Tatsuo Ishii

The Hermit Hacker <scrappy@hub.org> writes:

it seems that this problem is a type casting/promotion bug in the
source. The
routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
int2eq() in
backend/utils/adt/int.c via a function pointer
*fmgr_faddr(&key[0].sk_func). As
the type information for int2eq is lost via the function pointer,
the compiler
passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
int16's.
This particular bug goes away, if I for example change int2eq to:

bool
int2eq(int32 arg1, int32 arg2)
{
return (int16)arg1 == (int16)arg2;
}

Yow. I can't believe that we haven't seen this failure before on a
variety of platforms. Calling an ANSI-style function that has char or
short args is undefined behavior if you call it without benefit of a
prototype, because the parameter layout is allowed to be different.
Apparently, fewer compilers exploit that freedom than I would've thought.

Really, *all* of the builtin-function routines ought to take arguments
of type Datum and then do the appropriate Get() macro to extract what
they want from 'em. That's a depressingly large amount of work, but
at the very least the functions that take bool and int16 have to be
changed...

I concur in your Yow. Lots of changes, and I am surprised we have not
been bitten by this before. Added to TODO:

Fix function pointer calls to take Datum args for char and int2 args

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

We are aware of this bug. We have turned down optimization on PPC and
Alpha platforms until it is fixed, probably in 6.6.

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

---------- Forwarded message ----------
Date: Fri, 14 May 1999 14:50:58 -0400
From: Jack Howarth <howarth@nitro.med.uc.edu>
To: scrappy@hub.org
Subject: postgresql bug report

Marc,
In porting the RedHat 6.0 srpm set for a linuxppc release we
believe a bug has been identified in
the postgresql source for 6.5-0.beta1. Our development tools are as
follows...

glibc 2.1.1 pre 2
linux 2.2.6
egcs 1.1.2
the latest binutils snapshot

The bug that we see is that when egcs compiles postgresql at -O1 or
higher (-O0 is fine),
postgresql creates incorrectly formed databases such that when the user
does a destroydb
the database can not be destroyed. Franz Sirl has identified the problem
as follows...

it seems that this problem is a type casting/promotion bug in the
source. The
routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
int2eq() in
backend/utils/adt/int.c via a function pointer
*fmgr_faddr(&key[0].sk_func). As
the type information for int2eq is lost via the function pointer,
the compiler
passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
int16's.
This particular bug goes away, if I for example change int2eq to:

bool
int2eq(int32 arg1, int32 arg2)
{
return (int16)arg1 == (int16)arg2;
}

This moves away the type casting/promotion "work" from caller to the
callee and
is probably the right thing to do for functions used via function
pointers.

...because of the large number of changes required to do this, Franz
thought we should
pass this on to the postgresql maintainers for correction. Please feel
free to contact
Franz Sirl (Franz.Sirl-kernel@lauterbach.com) if you have any questions
on this bug
report.

--
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D. 231 Bethesda Avenue
NMR Facility Director Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics phone: (513) 558-4420
Univ. of Cincinnati College of Medicine fax: (513) 558-8474

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026