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

From Robert Haas
Subject Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Date
Msg-id CA+TgmoZpTW_A3--Mno=oFdc84DEQaDqQ0gsWmnt7xPifPWwRTw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Dave Cramer <davecramer@gmail.com>)
Responses Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Craig Ringer <craig.ringer@2ndquadrant.com>)
Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Jorge Solórzano <jorsol@gmail.com>)
List pgsql-jdbc
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.  Building with -O0 might help.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-jdbc by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication