Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre

From: Vitaly V(dot) Voronov <wizard_1024(at)tut(dot)by>
To: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre
Date: 2018-04-06 07:42:01
Message-ID: 3343581523000521@web56o.yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello,

06.04.2018, 02:18, "Peter Geoghegan" <pg(at)bowt(dot)ie>:
> On Thu, Apr 5, 2018 at 3:39 PM, PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>>  We have problem at our Master server (second time).
>>  From first time, we update CentOS to latest version (6.9)
>>  But today we have such bug:
>>  *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double
>>  free or corruption (!prev): 0x00000000022529e0 ***
>
> Can you get a full stack trace from a coredump?
>
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
>
> It would be particularly helpful if you were able to collect a
> coredump, and run "p *debug_query_string" from GDB.
>
> It would also be nice to be able to get the query string from some
> other source, such as the server log. Perhaps it can be correlated to
> something?
Sorry. I can't do this. Because, 1s - this is production and 2nd - it had been initialized as replica.
We use 2 server, and this server (with error) now initialized as secondary.
We use pgpool for switching servers.
And i posted full log from Postgres logs.
All other logs is clear.
>
>>  ======= Backtrace: =========
>>  /lib64/libc.so.6(+0x75dee)[0x7f6b19433dee]
>>  /lib64/libc.so.6(+0x78c80)[0x7f6b19436c80]
>>  postgres: postgres smsconsole [local]
>>  SELECT(tuplestore_end+0x17)[0x808887]
>>  postgres: postgres smsconsole [local]
>>  SELECT(ExecEndFunctionScan+0x75)[0x5e94e5]
>>  postgres: postgres smsconsole [local]
>>  SELECT(standard_ExecutorEnd+0x2e)[0x5cbaae]
>
> Offhand, I suspect that this could be a bug that is analogous to the
> one just fixed within tuplesort, by
> c2d4eb1b1fa252fd8c407e1519308017a18afed1. There is a fairly long
> history of these kinds of bugs, including one or two in tuplestore
> that I can recall from memory.
We have zabbix monitoring, which actively using pg_stat_* and pg_buffercache.
Can this cause such problem?

Can you answer, when such changes will be released in production?
>
> --
> Peter Geoghegan

Thanks for you answers!

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bossart, Nathan 2018-04-06 20:29:33 Re: BUG #14941: Vacuum crashes
Previous Message Michael Paquier 2018-04-06 02:47:53 Re: BUG #14941: Vacuum crashes