Thread: postgresql bug report (fwd)
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
To compile postgres using gcc 2.7.2.1 I had to modify 2 files src/interfaces/libpq++/pgconnection.ccsrc/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
Oleg Bartunov <oleg@sai.msu.su> writes:
> 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>
> #include <strstream> to #include <strstream.h>
I am seeing the same thing here with gcc 2.7.2.2. We need to adopt
a considered policy about whether libpq++ will still support gcc 2.7.*,
not just break it without thinking.
I'd vote for still supporting 2.7.*, but I know that the C++ library
shipped with this gcc release is not real up-to-date. It may not be
practical to support both latest-C++-spec compilers and the older
generation; I'm not sure what the issues are.
If the conclusion is "no", then the configure script ought to be
changed to not try to build libpq++ unless up-to-date libraries
are available.
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
> 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
> Oleg Bartunov <oleg@sai.msu.su> writes: > > 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> > > #include <strstream> to #include <strstream.h> > > I am seeing the same thing here with gcc 2.7.2.2. We need to adopt > a considered policy about whether libpq++ will still support gcc 2.7.*, > not just break it without thinking. > > I'd vote for still supporting 2.7.*, but I know that the C++ library > shipped with this gcc release is not real up-to-date. It may not be > practical to support both latest-C++-spec compilers and the older > generation; I'm not sure what the issues are. > > If the conclusion is "no", then the configure script ought to be > changed to not try to build libpq++ unless up-to-date libraries > are available. The addition/removal of '.h' has happened before. Some need it, some can't handle it. -- 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, Pennsylvania19026
> 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,
Pennsylvania19026
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,
Pennsylvania19026