Re: [HACKERS] SEGFAULT in HEAD with replication - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] SEGFAULT in HEAD with replication
Date
Msg-id CAMsr+YH0Xp5kUnUbx8K=iZGCOiU+LvTmLvLXS6S5BY7m0f8WbA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] SEGFAULT in HEAD with replication  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers


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 by date:

Previous
From: Dmitry Fedin
Date:
Subject: [HACKERS] [PATCH] Change missleading comment for tm_mon field of pg_tm structure
Next
From: Dave Cramer
Date:
Subject: Re: [HACKERS] SEGFAULT in HEAD with replication