[pgpool-general: 9161] Re: Segmentation fault

[Tatsuo Ishii]

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