Thread: Core dumps, i.e. how to track down a problem
Core dumps, i.e. how to track down a problem
From
oberpwd@anubis.network.com (Wade D. Oberpriller)
Date:
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
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