Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication

Поиск
Список
Период
Сортировка
От Jorge Solórzano
Тема Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Дата
Msg-id CA+cVU8Pa4NsJe3LyzTdd_t39WiUoNbphY9oAF_sWOSxsU2QuZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@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.  Building with -O0 might help.

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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [JDBC] SEGFAULT in HEAD with replication