Re: [HACKERS] SEGFAULT in HEAD with replication

Поиск
Список
Период
Сортировка
Искать
От
Dave Cramer
Тема
Re: [HACKERS] SEGFAULT in HEAD with replication
Дата
Msg-id
CADK3HHLdSE-64YLLOfJ1iiY7uXD+V0LmiWVnHROJSpcSmBw93w@mail.gmail.com
Ответ на
Список
Дерево обсуждения
[HACKERS] SEGFAULT in HEAD with replication Dave Cramer <davecramer@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Vladimir Gordiychuk <folyga@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Vladimir Gordiychuk <folyga@gmail.com>
Re: SEGFAULT in HEAD with replication Jorge Solórzano <jorsol@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Jorge Solórzano <jorsol@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Dave Cramer <davecramer@gmail.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Dave Cramer <davecramer@gmail.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Robert Haas <robertmhaas@gmail.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Jorge Solórzano <jorsol@gmail.com>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] SEGFAULT in HEAD with replication Jorge Solórzano <jorsol@gmail.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Jorge Solórzano <jorsol@gmail.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Craig Ringer <craig.ringer@2ndquadrant.com>
Re: [HACKERS] SEGFAULT in HEAD with replication Dave Cramer <davecramer@gmail.com>
Not sure you can get the exec. We are working on producing the BT from Travis-CI or I will build and run the test locally and get the trace

Dave Cramer

On 19 January 2017 at 15:31, Craig Ringer <craig.ringer@2ndquadrant.com> wrote:


On 20 Jan. 2017 04:13, "Robert Haas" <robertmhaas@gmail.com> wrote:
On Thu, Jan 19, 2017 at 12:09 PM, Dave Cramer <davecramer@gmail.com> wrote:
> I would have expected more, but this is what I have
>
>  bt full
> #0  InitPredicateLocks () at predicate.c:1250
>         i = <optimized out>
>         info = {num_partitions = 1, ssize = 140731424825288, dsize = 1,
>           max_dsize = 0, ffactor = 140731424836952, keysize =
> 140356326474085,
>           entrysize = 140728909791233, hash = 0x7ffe96960d58,
>           match = 0x16da2d1, keycopy = 0x7ffe96960d58, alloc = 0x1703af0,
>           hcxt = 0x16da2d0, hctl = 0x0}
>         max_table_size = 117899280
>         requestSize = <optimized out>
>         found = 0 '\000'

I would say that's not a valid stack trace.  There hasn't been a
change made to that file since October of last year, and the crash is
apparently recent; also, line 1250 in that file doesn't look like
something that can crash.  I would guess that you're using an
executable which doesn't match the core dump, or perhaps that you
don't have complete debug symbols.

You really need the same compiler flags, configure opts and preferably much the same compiler. Similar or same C library etc. 

Can't we get the executables from Travis CI or from whoever produced the core? Or get them to obtain a bt ?

В списке pgsql-hackers по дате отправления
От: Craig Ringer
Дата:
От: Tom Lane
Дата:
FAQ