MySQL Bugs: #102608: Segmentation fault in mysys/my

Bug #102608	Segmentation fault in mysys/my_malloc.c
Submitted:	16 Feb 2021 15:53	Modified:	18 Feb 2021 9:05
Reporter:	Purushottam Thakar	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: C API (client library)	Severity:	S3 (Non-critical)
Version:	5.6.41-enterprise-commercial	OS:	Red Hat (Red Hat Enterprise Linux Server release 7.6 (Maipo))
Assigned to:		CPU Architecture:	x86 (Linux 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019 x86_64 x86_64 x)

Description:
We have Mysql 5.6.41 running on RHEL 7.6 on customers setup.
The segmentation fault occurs in mysys/my_malloc.c

What we did: Our Application runs the query using mysql_real_query - SELECT * FROM ums_config (this table had 33 fields and one row)

What you wanted to happen: Execute query and return a result.

What actually happened: Segmentation fault

Backtrace:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `HttpServer'.
Program terminated with signal 11, Segmentation fault.
#0  0xf5d4b662 in my_malloc (size=8164, my_flags=1040) at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/mysys/my_malloc.c:52
52      /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/mysys/my_malloc.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install Cisco_VSMS-7.14.1-073d.x86_64
(gdb) bt
#0  0xf5d4b662 in my_malloc (size=8164, my_flags=1040) at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/mysys/my_malloc.c:52
#1  0xf5d49d11 in alloc_root (mem_root=0xfc73840c, length=2776) at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/mysys/my_alloc.c:224
#2  0xf5d1cec1 in unpack_fields (mysql=0xfc738174, data=0xfe1d2f70, alloc=0xfc73840c, fields=33, default_value=0 '\000', server_capabilities=2155870207)
    at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/sql-common/client.c:1436
#3  0xf5d1deaf in cli_read_query_result (mysql=0xfc738174) at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/sql-common/client.c:4304
#4  0xf5d1a746 in mysql_real_query (mysql=0xfc738174, query=0xfff89008 "SELECT * FROM ums_config", length=24)
    at /export/home/pb2/build/sb_0-29159266-1529068325.01/mysqlcom-pro-5.6.41/sql-common/client.c:4339
#5  0xf61d141a in execute (length=24, qstr=0xfff89008 "SELECT * FROM ums_config", this=0xfc738170) at /var/jenkins/workspace/VSMS-7.14.1/server/gpl/mysql-plusplus-3.1.0/lib/dbdriver.h:288
#6  mysqlpp::Query::use (this=this@entry=0xf272fc08, str=0xfff89008 "SELECT * FROM ums_config", len=len@entry=24)
    at /var/jenkins/workspace/VSMS-7.14.1/server/gpl/mysql-plusplus-3.1.0/lib/query.cpp:669
#7  0xf61d1774 in mysqlpp::Query::use (this=this@entry=0xf272fc08, s=...) at /var/jenkins/workspace/VSMS-7.14.1/server/gpl/mysql-plusplus-3.1.0/lib/query.cpp:652
#8  0xf698502b in mysqlpp::Query::storein_sequence<std::vector<UMSConfigDTO, std::allocator<UMSConfigDTO> > > (this=this@entry=0xf272fc08, con=std::vector of length 0, capacity 0, s=...)
    at /var/jenkins/workspace/VSMS-7.14.1/build/gpl/mysql-plusplus-3.1.0/mysql++/query.h:756
#9  0xf69865b8 in storein<UMSConfigDTO> (s=..., con=std::vector of length 0, capacity 0, this=0xf272fc08) at /var/jenkins/workspace/VSMS-7.14.1/build/gpl/mysql-plusplus-3.1.0/mysql++/query.h:901
#10 storein<std::vector<UMSConfigDTO> > (con=std::vector of length 0, capacity 0, this=0xf272fc08) at /var/jenkins/workspace/VSMS-7.14.1/build/gpl/mysql-plusplus-3.1.0/mysql++/query.h:882
#11 getAll<UMSConfigDTO> (object=..., connIn=connIn@entry=0xf272fe4c) at /var/jenkins/workspace/VSMS-7.14.1/server/applications/mysql++/src/dbInterface.hxx:260
#12 0xf697ae51 in dbUMSConfig::get (conn=conn@entry=0xf272fe4c) at /var/jenkins/workspace/VSMS-7.14.1/server/applications/mysql++/src/dbUMSConfig.cxx:63
#13 0xf7146d0e in CoolUMSConfig::load (emsg="", connIn=connIn@entry=0x0) at /var/jenkins/workspace/VSMS-7.14.1/server/applications/cool/CoolUMSConfig.cxx:205
#14 0x08078a3b in HttpConnectionHandler::run (this=0xf99ca018) at /var/jenkins/workspace/VSMS-7.14.1/server/bms/src/programs/httpserver/Http.cxx:691
#15 0xf76a043f in LThread::start_thread (obj=0xf99ca018) at /var/jenkins/workspace/VSMS-7.14.1/server/bms/src/libs/util/LThread.cxx:19
#16 0xf5b4fb4c in start_thread () from /lib/libpthread.so.0
#17 0xf5a7c01e in clone () from /lib/libc.so.6

How to repeat:
We have a core dump available so will attach once we have link how to attached.

We observing core dump on every 2-3 days on customers setup.

Updated Arch

Hi Mr. Thakar,

Thank you for your bug report.

However, the version that you are using is no longer supported. Support for version 5.6 has expired one month ago.

Also, this seems to be the problem of insufficient memory, but this is irrelevant in view that MySQL 5.6 is not longer in the maintenance.

Unsupported.

Hi Mr. Thakar,

There is yet another possibility.

It is possible that the application has used mysql_store_result() call instead of mysql_use_result() call, which could result in high memory consumption.

This behaviour is intentional and by design, which is why we have documented, in our Reference Manual, that first method should not be used for very large result sets.