Re: [HACKERS] SEGFAULT in HEAD with replication

From: Jorge Solórzano <jorsol(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dave Cramer <davecramer(at)gmail(dot)com>, Vladimir Gordiychuk <folyga(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [HACKERS] SEGFAULT in HEAD with replication
Date: 2017-01-19 21:31:57
Message-ID: CA+cVU8Pa4NsJe3LyzTdd_t39WiUoNbphY9oAF_sWOSxsU2QuZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

After many tries I get this:

#0 0x0000000000836950 in exec_bind_message (input_message=0x7ffce81048a0)
at postgres.c:1562
#1 0x000000000083a23d in PostgresMain (argc=1, argv=0x2bd93d8,
dbname=0x2bd9130 "test", username=0x2bd9110 "test") at postgres.c:4113
#2 0x00000000007aacd4 in BackendRun (port=0x2bd02d0) at postmaster.c:4300
#3 0x00000000007aa3fe in BackendStartup (port=0x2bd02d0) at
postmaster.c:3972
#4 0x00000000007a6a6c in ServerLoop () at postmaster.c:1712
#5 0x00000000007a6058 in PostmasterMain (argc=3, argv=0x2bac970) at
postmaster.c:1320
#6 0x00000000006ee046 in main (argc=3, argv=0x2bac970) at main.c:228

*********

#0 0x0000000000836950 in exec_bind_message (input_message=0x7ffce81048a0)
> at postgres.c:1562
> portal_name = 0x2c248c8 ""
> stmt_name = 0x2c248c9 "S_3"
> numPFormats = 0
> pformats = 0x0
> numParams = 0
> numRFormats = 0
> rformats = 0x0
> psrc = 0x2c698a8
> cplan = 0x0
> portal = 0x2bacc50
> query_string = 0x0
> saved_stmt_name = 0x0
> params = 0x0
> oldContext = 0x7ffce81047a0
> save_log_statement_stats = 0 '\000'
> snapshot_set = 0 '\000'
> msec_str =
> "\000H\020\350\374\177\000\000\345\b\224\000\000\000\000\000\020H\020\350\374\177\000\000\277ӿ\373w\351\001"
> __func__ = "exec_bind_message"
> #1 0x000000000083a23d in PostgresMain (argc=1, argv=0x2bd93d8,
> dbname=0x2bd9130 "test", username=0x2bd9110 "test") at postgres.c:4113
> firstchar = 66
> input_message = {data = 0x2c248c8 "", len = 11, maxlen = 1024,
> cursor = 9, long_ok = 0 '\000'}
> local_sigjmp_buf = {{__jmpbuf = {0, -8329243729337072925, 4625744,
> 140724201868624, 0, 0, -8329243729320295709, 8327513958265701091},
> __mask_was_saved = 1, __saved_mask = {__val = {0, 0,
> 15404064, 45969600, 51539607562, 140724201867680,
> 10064130, 0, 11951218, 11944554, 51539611844, 72198318239795616, 10292727,
> 15403032, 15402848, 15402848}}}}
> send_ready_for_query = 0 '\000'
> disable_idle_in_transaction_timeout = 0 '\000'
> __func__ = "PostgresMain"
> #2 0x00000000007aacd4 in BackendRun (port=0x2bd02d0) at postmaster.c:4300
> av = 0x2bd93d8
> maxac = 2
> ac = 1
> secs = 538176510
> usecs = 721824
> i = 1
> __func__ = "BackendRun"
> #3 0x00000000007aa3fe in BackendStartup (port=0x2bd02d0) at
> postmaster.c:3972
> bn = 0x2bd0490
> pid = 0
> __func__ = "BackendStartup"
> #4 0x00000000007a6a6c in ServerLoop () at postmaster.c:1712
> port = 0x2bd02d0
> i = 0
> rmask = {fds_bits = {8, 0 <repeats 15 times>}}
> selres = 1
> now = 1484861310
> readmask = {fds_bits = {56, 0 <repeats 15 times>}}
> nSockets = 6
> last_lockfile_recheck_time = 1484861307
> last_touch_time = 1484861007
> __func__ = "ServerLoop"
> #5 0x00000000007a6058 in PostmasterMain (argc=3, argv=0x2bac970) at
> postmaster.c:1320
> opt = -1
> status = 0
> userDoption = 0x2bce450 "/usr/local/pgsql/data"
> listen_addr_saved = 1 '\001'
> i = 64
> output_config_variable = 0x0
> __func__ = "PostmasterMain"
> #6 0x00000000006ee046 in main (argc=3, argv=0x2bac970) at main.c:228
>

I hope this helps.

Jorge Solórzano
me.jorsol.com

On Thu, Jan 19, 2017 at 11:13 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jan 19, 2017 at 12:09 PM, Dave Cramer <davecramer(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-01-19 21:32:27 Re: [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups
Previous Message Alvaro Herrera 2017-01-19 21:27:34 Re: [PATCH] Fix minor race in commit_ts SLRU truncation vs lookups

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2017-01-19 21:57:17 Re: [HACKERS] SEGFAULT in HEAD with replication
Previous Message Dave Cramer 2017-01-19 20:48:56 Re: [JDBC] SEGFAULT in HEAD with replication