[pgpool-hackers: 4236] Re: segmentation fault error

[稲垣毅 / INAGAKI，TSUYOSHI]

Hi, Ishii-san

Thanks for reply.

>As you said the memory area pointed by "node" was broken or smashed. The segfault was occurred inside >Execute() which is called when "execute" message was sent from frontend. Because there's no place to modify >"node" parameter inside Execute(), my guess is "node"
>had been already smashed before calling Execute(). The "node" memory area was created by SQL parser in >Parse() which was called when parse message arrived. So it is likely somewhere between Parse() and
>Execute() the "node" was smashed.
>
>Maybe you could insert "pool_has_function_call(node)" somewhere to see where the "node" memory was first >smashed.

I was understanding that by adding pool_has_function_call(node) between Parse() and Execute() I was able to catch the broken timings.
However, since I do not know the full details of the execution location, could you tell me where to add it specifically?

Regards,

Inagaki Tsuyoshi
<tsuyoshi.inagaki.ej �� hitachi.com>


-----Original Message-----
From: Tatsuo Ishii <ishii �� sraoss.co.jp> 
Sent: Monday, December 5, 2022 2:41 PM
To: 稲垣毅 / INAGAKI，TSUYOSHI <tsuyoshi.inagaki.ej �� hitachi.com>
Cc: pgpool-hackers �� pgpool.net
Subject: [!]Re: [pgpool-hackers: 4229] segmentation fault error

Hi Inagaki-san,

> Hi, Ishii-san.
> 
> Sorry for the late reply, I was organizing the information.
> 
>>case T_InsertStmt:
>>
>>which is absolutely nonsense because the stack #1 is processing T_List. There's no such a thing in a parse tree which consists of list of INSERT statements.
> 
>>From which information is the jump destination T_InsertStmt?
> #3 on the stack is inside case T_SelectStmt:, so it is recognized as a SELECT statement.
> Also, I could be confirmed that the SQL I was executing was a SELECT statement.

You are right. I was confused.

> #0 0x0000559ff3b977f4 in function_call_walker (node=0x1000100000000, 
> context=0x7ffcefcf1390) at utils/pool_select_walker.c:341
> #1 0x0000559ff3b9458d in raw_expression_tree_walker 
> (node=0x559ff531aa10, walker=0x559ff3b977e0 <function_call_walker>, 
> context=0x7ffcefcf1390) at rewrite/pool_timestamp.c:1454

As you said the memory area pointed by "node" was broken or smashed. The segfault was occurred inside Execute() which is called when "execute" message was sent from frontend. Because there's no place to modify "node" parameter inside Execute(), my guess is "node"
had been already smashed before calling Execute(). The "node" memory area was created by SQL parser in Parse() which was called when parse message arrived. So it is likely somewhere between Parse() and
Execute() the "node" was smashed.

Maybe you could insert "pool_has_function_call(node)" somewhere to see where the "node" memory was first smashed.

>>Can you share pgpool.conf and pgpool log?
> 
> I'll pick it up and send it to you.
> Please let me know if you need any additional information.
> 
> 
> pgpool log
> [2022-11-08 00:09:29][14402][main] WARNING:  child process with pid: 
> 24266 was terminated by segmentation fault
> [2022-11-08 00:09:29][14402][main] LOG:  fork a new child process with 
> pid: 10357
> 
> The previous log for pid:24266 is below.(It's old, so I don't think it 
> will affect it.)
> 
> [2022-11-07 21:00:02][24266][psql] LOG:  pool_send_and_wait: Error or 
> notice message from backend: : DB node id: 0 backend pid: 17873 
> statement: xxx

Unfortunately this does not help a lot.

> pgpool.conf
> I'll let you know what the parameters change.

Thanks for the info. Looks usual except num_init_children is high but I don't think it's insane if you have enough memory.

Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://secure-web.cisco.com/1fYVxin8zH8hlng3r-suiN-C7VulvEzr7WONu6t5m3izKSqDlQoEhQrJgXeKtn06exrtOqt4dgJQg-FCeNSdjt54nh96AA3WwtogVTnI1OgVP5z83rfSoIK6VY-teLIAM3RIb1MXwalp0CINozQSSc3sr0OvD36ddBNWnrcaLav3fx0w0lO5g162JDSK9SINgBah1lQ9NlwSoTVDdPY_mZxixUuoFuLHvh-xcBF1Djq-ekN_xNRlgc_lnmrW8DbfyMcHnwv6Ro_T2IxB6X1Ysgwayl3RuncqH30A0Phc77YssXJuZM9xYcDVMP7l5wUUUnJ53Q8MHnkaKvtCxEbYwcQ/http%3A%2F%2Fwww.sraoss.co.jp%2Findex_en%2F
Japanese:http://secure-web.cisco.com/1KeuoUlaOlZ1DKr6zzGW_o7WvLNaxyEqCmXbMMrLxJ85xxsr4G7r1GqtutkCQvwNtDAmxN0g6VqSId1AP5liyBLK-MewTmv49lNJe04SoqBYl37ud2QckxEi-sVG1yqvbN9bxAslfoKNaDeWOpxJK7S1wKYJtNSBp-TWCSYSGm3cj24dJYz0VVfWeCTyZqZgqRXem1L3tdyKxgtHJvGKNy4oH95xOYm4RvlDXilz0RF6vkCmcsvoXZ22UDvkRN8ZtF_11g_YvVr3TqnM-YmrTnyoLUi0Dw-o1Cy6iwh2PkQuIp_LzTcEFRZCQ1ievg3Mpo5Ev3SYwQIwQtLSWx06Kfg/http%3A%2F%2Fwww.sraoss.co.jp