[pgpool-general: 9162] Re: Segmentation fault
Emond Papegaaij
emond.papegaaij at gmail.com
Mon Jul 1 16:06:01 JST 2024
Hi,
No, it is very infrequent. In fact, I've only seen it once so far.
Best regards,
Emond
Op ma 1 jul 2024 om 08:03 schreef Tatsuo Ishii <ishii at sraoss.co.jp>:
> So far, I was not able to find any defect in the code, nor reproduce
> the segfault. Does it occur frequently?
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>
> > Thanks.
> >
> > I will look into the core using the binary.
> >
> > Best reagards,
> > --
> > Tatsuo Ishii
> > SRA OSS LLC
> > English: http://www.sraoss.co.jp/index_en/
> > Japanese:http://www.sraoss.co.jp
> >
> >> Hi,
> >>
> >> No, it was not. At that moment, we did not yet apply any patches to
> 4.5.2,
> >> so it was a plain 4.5.2 build. I've recreated the binary as it was
> built at
> >> that time.
> >>
> >> Best regards,
> >> Emond
> >>
> >> Op wo 26 jun 2024 om 08:30 schreef Tatsuo Ishii <ishii at sraoss.co.jp>:
> >>
> >>> Hi Emond,
> >>>
> >>> As Pengbo is busy, I am going to look into this instead of her.
> >>> Question: was the pgpool executable file same as the one I received at:
> >>> https://www.pgpool.net/pipermail/pgpool-general/2024-June/009203.html
> >>>
> >>> If not, can we share the pgpool executable file at that moment?
> >>>
> >>> Best reagards,
> >>> --
> >>> Tatsuo Ishii
> >>> SRA OSS LLC
> >>> English: http://www.sraoss.co.jp/index_en/
> >>> Japanese:http://www.sraoss.co.jp
> >>>
> >>> > Hi,
> >>> >
> >>> > Thank you for reporting this issue.
> >>> > I will look into it.
> >>> >
> >>> > On Wed, 22 May 2024 14:31:23 +0200
> >>> > Emond Papegaaij <emond.papegaaij at gmail.com> wrote:
> >>> >
> >>> >> Hi,
> >>> >>
> >>> >> Today one of our tests detected a segmentation fault in pgpool. At
> that
> >>> >> moment, the system runs with a single node, so no replication is
> >>> involved.
> >>> >> During one of the actions, the database is restarted. This seems to
> >>> match
> >>> >> exactly with the moment of the segmentation fault in pgpool. Below
> is
> >>> the
> >>> >> backtrace. I've attached the pgpool logs. You can find the
> segmentation
> >>> >> fault at timestamp 2024-05-22T08:47:04.231172. In the kernel logs,
> the
> >>> real
> >>> >> segmentation fault seems to occur a few seconds before that, at
> >>> 08:47:01,
> >>> >> right at the moment when the database is stopped.
> >>> >>
> >>> >> I've also attached the coredump itself. Ppgpool is version 4.5.2
> and it
> >>> was
> >>> >> compiled without debug symbols and with default compiler
> optimization.
> >>> I'm
> >>> >> not that deep into C development, so I'm not sure if this makes much
> >>> >> difference on the reliability of the dump. I obtained the backtrace
> by
> >>> >> rebuilding pgpool with debug symbols (but keeping the same
> optimization
> >>> >> settings).
> >>> >>
> >>> >> Best regards,
> >>> >> Emond
> >>> >>
> >>> >> #0 pfree (pointer=0x7fdabff0fdb8) at
> ../../src/utils/mmgr/mcxt.c:956
> >>> >> #1 0x00005593b38c5be5 in MemoryContextDelete
> (context=0x7fdabff0fdb8)
> >>> at
> >>> >> ../../src/utils/mmgr/mcxt.c:229
> >>> >> #2 0x00005593b389af93 in pool_query_context_destroy
> >>> >> (query_context=0x5593b4b28d38) at context/pool_query_context.c:125
> >>> >> #3 0x00005593b3896218 in pool_sent_message_destroy
> >>> >> (message=0x5593b4b2b5e8) at context/pool_session_context.c:468
> >>> >> #4 0x00005593b3896013 in pool_remove_sent_message (kind=80 'P',
> >>> >> name=0x5593b4b60740 "") at context/pool_session_context.c:399
> >>> >> #5 0x00005593b389692f in pool_add_sent_message
> >>> (message=0x5593b4b2b198) at
> >>> >> context/pool_session_context.c:643
> >>> >> #6 0x00005593b3881377 in Parse (frontend=0x5593b4b204f8,
> >>> >> backend=0x7fdabff096d8, len=4, contents=0x5593b4b35f98 "") at
> >>> >> protocol/pool_proto_modules.c:1588
> >>> >> #7 0x00005593b388523d in ProcessFrontendResponse
> >>> (frontend=0x5593b4b204f8,
> >>> >> backend=0x7fdabff096d8) at protocol/pool_proto_modules.c:2833
> >>> >> #8 0x00005593b3879b99 in read_packets_and_process
> >>> >> (frontend=0x5593b4b204f8, backend=0x7fdabff096d8, reset_request=0,
> >>> >> state=0x7ffd95ab31b0, num_fields=0x7ffd95ab31b6, cont=0x7ffd95ab31ab
> >>> >> "\001\223U") at protocol/pool_process_query.c:5117
> >>> >> #9 0x00005593b386ccbf in pool_process_query
> (frontend=0x5593b4b204f8,
> >>> >> backend=0x7fdabff096d8, reset_request=0) at
> >>> >> protocol/pool_process_query.c:247
> >>> >> #10 0x00005593b3865174 in do_child (fds=0x5593b4b078e0) at
> >>> >> protocol/child.c:467
> >>> >> #11 0x00005593b382aa4c in fork_a_child (fds=0x5593b4b078e0, id=6) at
> >>> >> main/pgpool_main.c:863
> >>> >> #12 0x00005593b3829e30 in PgpoolMain (discard_status=0 '\000',
> >>> >> clear_memcache_oidmaps=0 '\000') at main/pgpool_main.c:561
> >>> >> #13 0x00005593b38279e6 in main (argc=2, argv=0x7ffd95ac0568) at
> >>> >> main/main.c:365
> >>> >
> >>> >
> >>> > --
> >>> > Bo Peng <pengbo at sraoss.co.jp>
> >>> > SRA OSS LLC
> >>> > TEL: 03-5979-2701 FAX: 03-5979-2702
> >>> > URL: https://www.sraoss.co.jp/
> >>> > _______________________________________________
> >>> > pgpool-general mailing list
> >>> > pgpool-general at pgpool.net
> >>> > http://www.pgpool.net/mailman/listinfo/pgpool-general
> >>>
> > _______________________________________________
> > pgpool-general mailing list
> > pgpool-general at pgpool.net
> > http://www.pgpool.net/mailman/listinfo/pgpool-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20240701/7f7b7742/attachment.htm>
More information about the pgpool-general
mailing list