
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





Fri, 14 May 1999 16:49:44 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
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


Sat, 15 May 1999 00:37:26 +0400 (MSD)
Oleg Bartunov <oleg@sai.msu.su>
6.5 cvs: problem with includes in src/interfaces/libpq++/
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

Fri, 14 May 1999 17:46:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] postgresql bug report (fwd) 
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

Fri, 14 May 1999 17:59:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 6.5 cvs: problem with includes in
	src/interfaces/libpq++/
> 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

Sat, 15 May 1999 09:54:18 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] postgresql bug report (fwd) 
> 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

Sat, 15 May 1999 05:10:51 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postgresql bug report (fwd)
> 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, Pennsylvania 19026

Sat, 15 May 1999 05:12:03 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] 6.5 cvs: problem with includes in
	src/interfaces/libpq++/
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

Tue, 6 Jul 1999 23:47:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] postgresql bug report (fwd)