Thread: Help with Segmentation Fault
I just tried to upgrade to the lastest 7.3.2. I did a dumpall on my database and wiped out both my binary and data directories so I could start the install from scratch. The configure, make and make install work fine. No errors reported from initdb and postmaster starts no problem. As soon as I try to connect to template1 to restore my dumpall, I get a segmentation fault. If I try to do a createdb, I also get a segmentation fault. I had no problem making 7.2.? and setting it up. I'm running SuSE Linux 7.0 (s390) Patrick Bye Programmer / Analyst Westfair Foods Ltd. pbye@westfair.ca (403) 291-6538
"Patrick Bye (WFF)" <PBYE@Westfair.CA> writes:
> I just tried to upgrade to the lastest 7.3.2. I did a dumpall on my
> database and wiped out both my binary and data directories so I could start
> the install from scratch. The configure, make and make install work fine.
> No errors reported from initdb and postmaster starts no problem. As soon as
> I try to connect to template1 to restore my dumpall, I get a segmentation
> fault. If I try to do a createdb, I also get a segmentation fault. I had
> no problem making 7.2.? and setting it up. I'm running SuSE Linux 7.0
> (s390)
Do the regession tests ('make check') pass with the 7.3.2 you built?
-Doug
"Patrick Bye (WFF)" <PBYE@Westfair.CA> writes:
> I just tried to upgrade to the lastest 7.3.2. I did a dumpall on my
> database and wiped out both my binary and data directories so I could start
> the install from scratch. The configure, make and make install work fine.
> No errors reported from initdb and postmaster starts no problem. As soon as
> I try to connect to template1 to restore my dumpall, I get a segmentation
> fault. If I try to do a createdb, I also get a segmentation fault.
You have not provided a whole lot of detail here, but reading between
the lines I guess that it is psql core-dumping, not the backend?
Most likely that would be a problem of incompatibility with one of the
shared libraries that psql depends on. It's difficult to say more than
that with no details though. Did you build 7.3.2 yourself (if so, with
what configure switches) or install an RPM (if so, whose)? Can you
provide a stack trace from the segfault core dump? Does ldd on the psql
executable report a sane-looking set of shlib dependencies?
regards, tom lane
I did build postgres myself using the simple installation instructions
provided on the website
configure
gmake
gmake install
I'm a linux newbie so most of the stuff you mention, I don't know how to do.
I believe that psql is dumping because postmaster still runs after the
segmentation fault. Same goes for createdb. After I sent this note, I
downloaded 7.2.4 and did the same install as I did for 7.3.2 and everything
worked fine. How do I do a stack trace?
Patrick Bye
Programmer / Analyst
Westfair Foods Ltd.
pbye@westfair.ca
(403) 291-6538
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Wednesday, February 12, 2003 9:07 PM
To: Patrick Bye (WFF)
Cc: 'pgsql-general@postgresql.org'
Subject: Re: [GENERAL] Help with Segmentation Fault
"Patrick Bye (WFF)" <PBYE@Westfair.CA> writes:
> I just tried to upgrade to the lastest 7.3.2. I did a dumpall on my
> database and wiped out both my binary and data directories so I could
start
> the install from scratch. The configure, make and make install work fine.
> No errors reported from initdb and postmaster starts no problem. As soon
as
> I try to connect to template1 to restore my dumpall, I get a segmentation
> fault. If I try to do a createdb, I also get a segmentation fault.
You have not provided a whole lot of detail here, but reading between
the lines I guess that it is psql core-dumping, not the backend?
Most likely that would be a problem of incompatibility with one of the
shared libraries that psql depends on. It's difficult to say more than
that with no details though. Did you build 7.3.2 yourself (if so, with
what configure switches) or install an RPM (if so, whose)? Can you
provide a stack trace from the segfault core dump? Does ldd on the psql
executable report a sane-looking set of shlib dependencies?
regards, tom lane
"Patrick Bye (WFF)" <PBYE@Westfair.CA> writes:
> I did build postgres myself using the simple installation instructions
> provided on the website
> configure
> gmake
> gmake install
Hm, that should work. What do you get from "ldd" on the psql executable?
> How do I do a stack trace?
If you aren't getting a core file from the segfault, try "ulimit -c unlimited".
Once you have a core file, do
gdb /path/to/psql core
gdb> bt
gdb> quit
The trace will be a lot more informative if you first rebuild with
debugging support (configure --enable-debug, then gmake clean all install).
regards, tom lane