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

[Tatsuo Ishii]

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 at entry=0x1177128, backend=backend at entry=0x7f3d27e1a690, len=<optimized out>, contents=<optimized out>,
>      contents at entry=0x117d558 "") at protocol/pool_proto_modules.c:1682
> #2 0x00000000004400cf in ProcessFrontendResponse (frontend=frontend at entry=0x1177128, backend=backend at entry=0x7f3d27e1a690) at protocol/pool_proto_modules.c:2750
> #3 0x0000000000433086 in pool_process_query (frontend=0x1177128, backend=0x7f3d27e1a690, reset_request=reset_request at entry=0) at protocol/pool_process_query.c:263
> #4 0x000000000042c549 in do_child (fds=fds at 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 at entry=1 '\001', clear_memcache_oidmaps=clear_memcache_oidmaps at 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 at hitachi.com
> 
> 
> -----Original Message-----
> From: Tatsuo Ishii <ishii at sraoss.co.jp> 
> Sent: Tuesday, December 6, 2022 2:38 PM
> To: 稲垣毅 / INAGAKI，TSUYOSHI <tsuyoshi.inagaki.ej at hitachi.com>
> Cc: pgpool-hackers at 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-taNptd9lrkLBUS2vahFRGaMD8jjFuKJFX0-gfOFE2vaGEvwdBOABNIH4ZrlHnxy9oALNPN8FTzTGx-AwhmQuKQt5EbONTZkc0fKJdwc4hDFwojA1H6VrZburXfdfUexT9hwCm9UDykVLvtFZGDME2B_nggSzC5OwXYaTVAbjtwVTKF3h9mPY-I3Q1KKUd8WXEgEhWf6-q018WSqd1cdrhn7F3x5OLvCMwj3TApiojUcNMGKhWgHZixddyGnNHjGDQEKQT4sRh0PiQGTXte1dkkq5zNeu8ootE8H0mUQxt0ikCVX3TpPob0XA/http%3A%2F%2Fwww.sraoss.co.jp%2Findex_en%2F
> Japanese:http://secure-web.cisco.com/1uXKL5eIBEMfsnu4GEKfGh74Rqgx0dIe8aQjKKej6TlFgRQ-tlMWBF2N1bdvpzyEmRdcToe5zJQ3d2xSZbNNd2g6MTlAcdr6jRKui3Carub3j_wouZPrCwdyEyZSqYHCL1VA3tGtu1KAfQs57IHx9lkBq4ibRfuWlWeH3FKkLiN6Y7Kom_aIqOhgbBiShGxJRWYZvDTNzHiDgXah5l2QE-7WJYg8OsO83AcL3vAUm_Bog6M-DmdBxHOojrBEfySPDdyl0VnC91F8c2IvthosORJgOiiS0UM1HTIiudRDmX7BJXSUHdVw-zB_nIpWKtbfcVjyh_I4bNELi9pxJO2nyNw/http%3A%2F%2Fwww.sraoss.co.jp
>