Skip site navigation (1) Skip section navigation (2)

Re: Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com

From: "Riendeau, Mike" <mike(dot)riendeau(at)analog(dot)com>
To: "Riendeau, Mike" <Mike(dot)Riendeau(at)exchange(dot)analog(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com
Date: 2002-03-04 19:12:45
Message-ID: D84A32D1A483D211A38F0060B06993D00875FBF2@wilmexm1.analog.com (view raw or flat)
Thread:
Lists: pgsql-bugs
 Follow up:

  PGv7.2 still suffers from the Seg. Fault on exit problem reported below
  on that system.
  
  However, Ran the new v7.2 on a new machine with the following config:
  
   Architecture (example: Intel Pentium)  	: Sun sparc, Ultra-2

   Operating System (example: Linux 2.0.26 ELF) 	: Solaris 2.8

   PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.2

   Compiler used (example:  gcc 2.95.2)		: gcc 2.95.2

  On, the new machine, the problem goes away. After some investigation,
  it appears to be some problem with our run-time linker cleaning up
  on the older systems.

  Regards,

     M Riendeau

  

-----Original Message-----
From: Riendeau, Mike [mailto:Mike(dot)Riendeau(at)exchange(dot)analog(dot)com]
Sent: Friday, February 01, 2002 4:04 PM
To: Tom Lane; Riendeau, Mike
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: RE: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build
com mands 


Your name		: Mike Riendeau
Your email address	: mike(dot)riendeau(at)analog(dot)com


System Configuration
---------------------
  Architecture (example: Intel Pentium)  	: Sun Sparc 20

  Operating System (example: Linux 2.0.26 ELF) 	: Solaris 2.5.1

  PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3

  Compiler used (example:  gcc 2.95.2)		: gcc 2.95.2


Please enter a FULL description of your problem:
------------------------------------------------

 I am having a problem with v7.1.3 PostgreSQL commands generating
 Seg. Faults on exit. (Continued)

 Steps taken on this pass:

 1) built readline4.2a successfully.

 2) Ran PGv7.1.3 configure as follows with a clean cache.

   ./configure --prefix=/home/mriendea --with-tcl
--with-tclconfig=/home/mriendea/lib --with-tkconfig=/home/mriendea/lib
--with-includes=/home/mriendea/include --with-pgport=8000 --with-odbc
--enable-debug --with-libs=/home/mriendea/lib --enable-debug

   Without 'gmake install' of the new readline lib, the script sees
   the same readline used to build PGv7.0.2 and completes successfully.
   Of course the Seg Fault behavior is apparent.

 3) 'gmake install' of the new readline lib.

 4) Ran PGv7.1.3 configure with a clean cache again. The script now sees
    the new readline4.2a lib and crashes with the identical
    problem reported by Holger Mittewald bug #490. (test following optreset
    bails the config script for some reason.)

    rpath is the same (at least in all Makes in the source root)
    Both config runs have the same parameters. So, something other
    than the setting of rpath is going on here. Or I do not understand
    how it all works (Definite possibility).


 Synopsys of configure with above switches:

                           PROCESS

 Tested     readline    Config   gmake  installed    run
 version                                 libs
           -----------------------------------------------------
 Pgv7.0.2    system    yes       yes     v7.0.2     yes

 Pgv7.1.3    system    yes       yes     v7.0.2     v7.1.3 pgsql,
                                                    createdb seem to
                                                    work with new db.
                                                    (brief testing)

 Pgv7.1.3    system    yes       yes     v7.1.3     Seg. Faults on exit
                                                     for pgsql, createdb ...

 Pgv7.1.3    v4.2a     bails     n/a     n/a        n/a
                       after
                       optreset          


 Giving up soon,

  Mike Riendeau

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2002-03-04 19:21:10
Subject: Bug #607: to_date() function bug
Previous:From: Reinhard MaxDate: 2002-03-04 11:10:39
Subject: Re: Indexes not always used after inserts/updates/vacuum

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group