MySQL Bugs: #88129: valgrind test Syscall param socketcall.sendto(msg) points to uninitialised byte

Bug #88129	valgrind test Syscall param socketcall.sendto(msg) points to uninitialised byte
Submitted:	18 Oct 2017 3:30	Modified:	7 Dec 2017 14:47
Reporter:	yghmgl yang	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.6.37	OS:	CentOS
Assigned to:		CPU Architecture:	Any
Tags:	debug valgrind-build

Description:
==64119== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==64119==    at 0x504A72B: send (in /usr/lib64/libpthread-2.17.so)
==64119==    by 0xEC3D7B: inline_mysql_socket_send (mysql_socket.h:759)
==64119==    by 0xEC4682: vio_write (viosocket.c:192)
==64119==    by 0x729767: net_write_raw_loop(st_net*, unsigned char const*, unsigned long) (net_serv.cc:496)
==64119==    by 0x729A7D: net_write_packet (net_serv.cc:632)
==64119==    by 0x7290A9: net_flush (net_serv.cc:218)
==64119==    by 0x72E4EB: net_send_eof(THD*, unsigned int, unsigned int) (protocol.cc:294)
==64119==    by 0x72EC06: Protocol::send_eof(unsigned int, unsigned int) (protocol.cc:555)
==64119==    by 0x72EA2F: Protocol::end_statement() (protocol.cc:502)
==64119==    by 0x7E93D1: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1803)
==64119==    by 0x7E7037: do_command(THD*) (sql_parse.cc:1040)
==64119==    by 0x20973B67: threadpool_process_request(THD*) (threadpool_common.cc:321)
==64119==    by 0x20976A37: handle_event(connection_t*) (threadpool_unix.cc:1611)
==64119==    by 0x20976C94: worker_main(void*) (threadpool_unix.cc:1664)
==64119==    by 0xB99FDC: pfs_spawn_thread (pfs.cc:1860)
==64119==    by 0x5043DC4: start_thread (in /usr/lib64/libpthread-2.17.so)
==64119==    by 0x61AC21C: clone (in /usr/lib64/libc-2.17.so)
==64119==  Address 0x35add0e6 is 134 bytes inside a block of size 69,639 alloc'd
==64119==    at 0x4C2BBB8: realloc (vg_replace_malloc.c:785)                                               
==64119==    by 0xAD11C9: my_realloc (my_malloc.c:99)
==64119==    by 0x728EF3: net_realloc (net_serv.cc:165)
==64119==    by 0x729F5C: net_read_packet(st_net*, unsigned long*) (net_serv.cc:845)
==64119==    by 0x729FE7: my_net_read (net_serv.cc:889)
==64119==    by 0x7E6DC6: do_command(THD*) (sql_parse.cc:973)
==64119==    by 0x20973B67: threadpool_process_request(THD*) (threadpool_common.cc:321)
==64119==    by 0x20976A37: handle_event(connection_t*) (threadpool_unix.cc:1611)
==64119==    by 0x20976C94: worker_main(void*) (threadpool_unix.cc:1664)
==64119==    by 0xB99FDC: pfs_spawn_thread (pfs.cc:1860)
==64119==    by 0x5043DC4: start_thread (in /usr/lib64/libpthread-2.17.so)
==64119==    by 0x61AC21C: clone (in /usr/lib64/libc-2.17.so)
==64119==  Uninitialised value was created by a client request
==64119==    at 0xAC907F: free_root (my_alloc.c:391)
==64119==    by 0x7E95AF: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1829)
==64119==    by 0x7E7037: do_command(THD*) (sql_parse.cc:1040)
==64119==    by 0x20973B67: threadpool_process_request(THD*) (threadpool_common.cc:321)
==64119==    by 0x20976A37: handle_event(connection_t*) (threadpool_unix.cc:1611)
==64119==    by 0x20976C94: worker_main(void*) (threadpool_unix.cc:1664)
==64119==    by 0xB99FDC: pfs_spawn_thread (pfs.cc:1860)
==64119==    by 0x5043DC4: start_thread (in /usr/lib64/libpthread-2.17.so)
==64119==    by 0x61AC21C: clone (in /usr/lib64/libc-2.17.so)

How to repeat:
pquery is random execute sql statement, so it hard to find which statement cause this issue,but it happened every day in my daily test.

Suggested fix:
this issue is report by valgrind while i test the mysql-server with pquery on valgrind mode, and i don't know if it is a bug.

Hi!

Thank you for your bug report.

Before we proceed, please, we have to be certain about one fact. Are you using our GPL binary ???

You have a thread stack that does not indicate that it is coming from our GPL binary.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".