Re: [HACKERS] SEGFAULT in HEAD with replication
От | Dave Cramer |
---|---|
Тема | Re: [HACKERS] SEGFAULT in HEAD with replication |
Дата | |
Msg-id | CADK3HHLdSE-64YLLOfJ1iiY7uXD+V0LmiWVnHROJSpcSmBw93w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication (Craig Ringer <craig.ringer@2ndquadrant.com>) |
Список | pgsql-hackers |
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 say that's not a valid stack trace. There hasn't been a
> 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'
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 по дате отправления: