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

[稲垣毅 / INAGAKI，TSUYOSHI]

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.

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-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