Core dumps, i.e. how to track down a problem

Started by Wade D. Oberprillerover 25 years ago2 messagesgeneral
Jump to latest
#1Wade D. Oberpriller
oberpwd@anubis.network.com

Hello,

I am trying to track down a problem with PL/Perl. I am running the following
configuration:

PostgreSQL 7.0.2
Solaris 2.5.1
Perl 5.005_03
gcc 2.7.2.2
ld 2.0

I am creating the plperl language and can create functions in this language.
Whenever I try to execute one of these functions, the postgres server process
crashes. Does this process leave a core dump or some kind of trace to be able to
learn more about what is happening? All it does now is report that the
server process aborted with a status 11.

Is there any extra flags to turn on, or compile with that could help?

Wade Oberpriller
StorageTek
oberpwd@netowrk.com

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Wade D. Oberpriller (#1)
Re: Core dumps, i.e. how to track down a problem

oberpwd@anubis.network.com (Wade D. Oberpriller) writes:

Whenever I try to execute one of these functions, the postgres server
process crashes. Does this process leave a core dump or some kind of
trace to be able to learn more about what is happening? All it does
now is report that the server process aborted with a status 11.

There should be a core file in the database subdirectory
($PGDATA/base/yourdbname/core). If you don't find one there, the
odds are that you started the postmaster with "ulimit -c 0" which
prevents coredumps. (Unfortunately, on some platforms this is the
default environment for anything started from a boot script.) Restart
the postmaster with "ulimit -c unlimited" and try again.

Once you have the core file, use gdb to get a backtrace:

gdb /path/to/postgres/executable /path/to/corefile
bt
quit

Is there any extra flags to turn on, or compile with that could help?

The corefile will be more informative if you compiled with -g, but
a backtrace may be useful even without.

regards, tom lane