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

[稲垣毅 / INAGAKI，TSUYOSHI]

Hi, Ishii-san

Thanks for replay.
The processing I put in to activate the trap is as follows.

>	query_context->parse_tree = 0 ;  <--- add
> 	pool_has_function_call(query_context->parse_tree); <--- add
> 
> 	if (rewrite_msg)
> 		pfree(rewrite_msg);
> 	return POOL_CONTINUE;

Since the original phenomenon was also a segmentation fault, it is recognized that this trap will cause a segmentation fault when the area destruction is reproduced.
It is said that 0 is not proof of a trap, but how can it be proof of a trap?

Regards,

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


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

Hi Iagaki-san,

Sorry for late reply.

> Hi, Ishii-san
> 
> Please allow me to check that my understanding is correct.
> I created a custom version by embedding the processing you suggested.
> Currently, it cannot be reproduced, so when I set the node to 0 just 
> before the corrected part and confirmed it, it was segmentation.

You mean you modified the source code of Bind() something like this?

> 	pool_has_function_call(0); <--- add
> 
> 	if (rewrite_msg)
> 		pfree(rewrite_msg);
> 	return POOL_CONTINUE;

If so, of course pool_has_function_call() segfaults because of reference to 0x00.
But this does not prove anything. Can you please elaborate?

> The stack is as follows.
> #0 pool_has_function_call (node=0x0) at utils/pool_select_walker.c:67
> #1 0x000000000043aa6e in Bind (frontend=frontend �� entry=0x1177128, backend=backend �� entry=0x7f3d27e1a690, len=<optimized out>, contents=<optimized out>,
>      contents �� entry=0x117d558 "") at 
> protocol/pool_proto_modules.c:1682
> #2 0x00000000004400cf in ProcessFrontendResponse 
> (frontend=frontend �� entry=0x1177128, 
> backend=backend �� entry=0x7f3d27e1a690) at 
> protocol/pool_proto_modules.c:2750
> #3 0x0000000000433086 in pool_process_query (frontend=0x1177128, 
> backend=0x7f3d27e1a690, reset_request=reset_request �� entry=0) at 
> protocol/pool_process_query.c:263
> #4 0x000000000042c549 in do_child (fds=fds �� entry=0x11b3310) at 
> protocol/child.c:449
> #5 0x00000000004060e5 in fork_a_child (fds=0x11b3310, id=30) at 
> main/pgpool_main.c:682
> #6 0x000000000040cc99 in PgpoolMain (discard_status=discard_status �� entry=1 '\001', clear_memcache_oidmaps=clear_memcache_oidmaps �� entry=0 '\000')
>      at main/pgpool_main.c:410
> #7 0x0000000000404247 in main (argc=<optimized out>, argv=<optimized 
> out>) at main/main.c:365
> 
> By the process embedded this time, it will crash immediately after the 
> memory is destroyed, and it is recognized that the inside of Bind() 
> can be identified as the memory destruction location from the call stack.
> In the previous message, it was said that memory was destroyed between 
> Parse() and Execute(), and there was no node update in Execute().
> The embedded part this time is the end of Bind() and the beginning of 
> Execute(), so if it crashes in Bind(), it is recognized that memory 
> destruction occurred somewhere in Bind() .
> If it goes down in Execute(), we recognize that memory destruction 
> occurred somewhere between Bind() completion and Execute() call.
> After being able to reproduce with the custom version, if it goes down 
> in Bind(), embed pool_has_function_call() calls everywhere in Bind() 
> to identify the memory corruption location, and If it goes down in 
> Execute(), is it correct to identify the location of memory corruption 
> by embedding pool_has_function_call() calls everywhere from the completion of Bind() to the start of Execute()?
> 
> Regards,
> 
> Inagaki Tsuyoshi
> tsuyoshi.inagaki.ej �� hitachi.com
> 
> 
> -----Original Message-----
> From: Tatsuo Ishii <ishii �� sraoss.co.jp>
> Sent: Tuesday, December 6, 2022 2:38 PM
> To: 稲垣毅 / INAGAKI，TSUYOSHI <tsuyoshi.inagaki.ej �� hitachi.com>
> Cc: pgpool-hackers �� pgpool.net
> Subject: [!]Re: [pgpool-hackers: 4229] segmentation fault error
> 
>>>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?
> 
> For starters, in Execute() here:
> 
> 	query_context = bind_msg->query_context;
> 	node = bind_msg->query_context->parse_tree;
> 	query = bind_msg->query_context->original_query;
> 
> 	pool_has_function_call(node); <--- add
> 
> For bind() here (at the very end of bind()):
> 
> 	pool_has_function_call(query_context->parse_tree); <--- add
> 
> 	if (rewrite_msg)
> 		pfree(rewrite_msg);
> 	return POOL_CONTINUE;
> }
> 	
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: 
> http://secure-web.cisco.com/1OV56I5WqRIdDvlXZNKgZXBE3hcMVz-taNptd9lrkL
> BUS2vahFRGaMD8jjFuKJFX0-gfOFE2vaGEvwdBOABNIH4ZrlHnxy9oALNPN8FTzTGx-Awh
> mQuKQt5EbONTZkc0fKJdwc4hDFwojA1H6VrZburXfdfUexT9hwCm9UDykVLvtFZGDME2B_
> nggSzC5OwXYaTVAbjtwVTKF3h9mPY-I3Q1KKUd8WXEgEhWf6-q018WSqd1cdrhn7F3x5OL
> vCMwj3TApiojUcNMGKhWgHZixddyGnNHjGDQEKQT4sRh0PiQGTXte1dkkq5zNeu8ootE8H
> 0mUQxt0ikCVX3TpPob0XA/http%3A%2F%2Fwww.sraoss.co.jp%2Findex_en%2F
> Japanese:http://secure-web.cisco.com/1uXKL5eIBEMfsnu4GEKfGh74Rqgx0dIe8
> aQjKKej6TlFgRQ-tlMWBF2N1bdvpzyEmRdcToe5zJQ3d2xSZbNNd2g6MTlAcdr6jRKui3C
> arub3j_wouZPrCwdyEyZSqYHCL1VA3tGtu1KAfQs57IHx9lkBq4ibRfuWlWeH3FKkLiN6Y
> 7Kom_aIqOhgbBiShGxJRWYZvDTNzHiDgXah5l2QE-7WJYg8OsO83AcL3vAUm_Bog6M-Dmd
> BxHOojrBEfySPDdyl0VnC91F8c2IvthosORJgOiiS0UM1HTIiudRDmX7BJXSUHdVw-zB_n
> IpWKtbfcVjyh_I4bNELi9pxJO2nyNw/http%3A%2F%2Fwww.sraoss.co.jp
>