Thread: [BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11:Segmentation fault
[BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11:Segmentation fault
From
naveenallin@gmail.com
Date:
The following bug has been logged on the website: Bug reference: 14531 Logged by: Naveen Chalmeti Email address: naveenallin@gmail.com PostgreSQL version: 9.6.1 Operating system: Ubuntu 14.04.1 LTS Description: We are facing frequent crash issue in postgresql due to segmentation fault. We have tried various ways to debug the issue such as enabling debug level log etc., but we could not get any idea what is the reason behind the crash. During the crash we have got a system crash file and extracted to get the back trace. Unluckily we are using postgres release binary using which we cannot get the full pledged back trace. Rough Backtrace: gdb -se /usr/lib/postgresql/9.6/bin/postgres --core=CoreDump GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/postgresql/9.6/bin/postgres...(no debugging symbols found)...done. [New LWP 14138] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `postgres: 9.6/main: postgres Database 127.0.0.1(58814) SELECT '. Program terminated with signal SIGSEGV, Segmentation fault. (gdb) bt full #0 0x00007fddcbc4e4ec in ExecClearTuple () No symbol table info available. #1 0x00007fddcbc63fb8 in ExecEndSeqScan () No symbol table info available. #2 0x00007fddcbc42f4c in standard_ExecutorEnd () No symbol table info available. #3 0x00007fddcbc0d744 in PortalCleanup () No symbol table info available. #4 0x00007fddcbe81c92 in PortalDrop () No symbol table info available. #5 0x00007fddcbd5ee81 in PostgresMain () No symbol table info available. #6 0x00007fddcbae43fb in ?? () No symbol table info available. #7 0x00007fddcbcfe06b in PostmasterMain () No symbol table info available. #8 0x00007fddcbae5142 in main () No symbol table info available. As it is affecting our production environment please do help us quickly. Thanks in advance. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault
From
Tom Lane
Date:
naveenallin@gmail.com writes:
> We are facing frequent crash issue in postgresql due to segmentation fault.
> We have tried various ways to debug the issue such as enabling debug level
> log etc., but we could not get any idea what is the reason behind the crash.
The postmaster should at least have logged what statement a crashed
backend was running (assuming you've not disabled the statistics
subsystem). Is there any consistency to that? It might be worth
turning on full statement logging (log_statement=all) so that you
can see everything the crashed sessions did.
The backtrace you show doesn't look much like any known 9.6 bug,
so we'd be very interested if you can put together a reproducible
test case.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #14531: server process (PID 12714) was terminated bysignal 11: Segmentation fault
From
NAVEEN CHALIMETI
Date:
Thanks for your reply firstly.
I did not mention anything about logs thinking the back trace would be enough to solve the issue. Sorry for that.
I have enabled the log_statement=all already and each time it gives different queries. But until now i have seen postmaster crashed during SELECT query.
Eg: Crashed yesterday while executing query [PID] 11221 DETAIL: Failed process was running: select n.nspname, c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid, pg_get_expr(d.adbin, d.adrelid), case t.typtype when 'd' then t.typbasetype else 0 end, t.typtypmod, c.relhasoids from (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace n on n.oid = c.relnamespace and c.oid = 19175) inner join pg_catalog.pg_attribute a on (not a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d on a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order by n.nspname, c.relname, attnum
For your Information the previous query in the log is "select COLUMN_VALUE from TABLE_NAME where COLUMN_VALUE=3"
The crash is reproducible with different queries.
Previous crashed query(just format) log:- select column1,column2, column3 from table_name where column4>-1
Regards,
Naveen Ch.
On Tue, Feb 7, 2017 at 8:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
naveenallin@gmail.com writes:
> We are facing frequent crash issue in postgresql due to segmentation fault.
> We have tried various ways to debug the issue such as enabling debug level
> log etc., but we could not get any idea what is the reason behind the crash.
The postmaster should at least have logged what statement a crashed
backend was running (assuming you've not disabled the statistics
subsystem). Is there any consistency to that? It might be worth
turning on full statement logging (log_statement=all) so that you
can see everything the crashed sessions did.
The backtrace you show doesn't look much like any known 9.6 bug,
so we'd be very interested if you can put together a reproducible
test case.
regards, tom lane
Re: [BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault
From
Tom Lane
Date:
NAVEEN CHALIMETI <naveenallin@gmail.com> writes:
> Thanks for your reply firstly.
> I did not mention anything about logs thinking the back trace would be
> enough to solve the issue. Sorry for that.
> I have enabled the *log_statement=all* already and each time it gives
> different queries. But until now i have seen postmaster crashed during
> SELECT query.
> ...
> The crash is reproducible with different queries.
Hm. Have you looked at more than one core dump? Is it always the same
backtrace?
Those queries don't look particularly exciting, so I'm now thinking the
problem is something unusual. Do you have any nondefault extensions
installed? Maybe you built the server with some unusual options?
I dislike blaming hardware problems, but we shouldn't rule out that
possibility either, unless you're seeing this on more than one machine.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #14531: server process (PID 12714) was terminated bysignal 11: Segmentation fault
From
NAVEEN CHALIMETI
Date:
We have not looked into the previous core dump. We will look into the core dumps and let u know.
We have just installed by using the command "sudo apt-get install postgresql postgresql-contrib", nothing else options we have used. And we are using psqlodbc driver as interface with our application.
./configure --with-unixodbc=/usr/bin --with-libpq=/usr/lib
this is the command to configure unix odbc.
I'm not sure whether this is because of hardware or postmaster. We will try this in different machines also for sure. Our production environment is suffering from this issue for many days. I hope will get a proper reason and solution soon.
We are very pleasure to hear from you which helps me to resolve this as soon as possible.
Regards,
Naveen Chalmeti
On Tue, Feb 7, 2017 at 12:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
NAVEEN CHALIMETI <naveenallin@gmail.com> writes:
> Thanks for your reply firstly.
> I did not mention anything about logs thinking the back trace would be
> enough to solve the issue. Sorry for that.
> I have enabled the *log_statement=all* already and each time it gives
> different queries. But until now i have seen postmaster crashed during
> SELECT query.
> ...
> The crash is reproducible with different queries.
Hm. Have you looked at more than one core dump? Is it always the same
backtrace?
Those queries don't look particularly exciting, so I'm now thinking the
problem is something unusual. Do you have any nondefault extensions
installed? Maybe you built the server with some unusual options?
I dislike blaming hardware problems, but we shouldn't rule out that
possibility either, unless you're seeing this on more than one machine.
regards, tom lane