MySQL Bugs: #76886: User application crash according to mysql client library bug

Bug #76886	User application crash according to mysql client library bug
Submitted:	29 Apr 2015 13:27	Modified:	30 Apr 2015 13:49
Reporter:	Oleg Tsarev	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Connector / C	Severity:	S2 (Serious)
Version:	5.5.31	OS:	Linux (CentOS 6.5 Final)
Assigned to:		CPU Architecture:	Any

Description:
My C++ application uses MySQL C connector and concurrently open connections to mysql server, execute few queries and close connections.

I received the crash on application startup, when several threads simultaneously attempt to open connections.

Backtrace:
(gdb) bt
#0  0x000000000072aa22 in my_stat ()
#1  0x000000000072ba7f in my_read_charset_file ()
#2  0x000000000072c77d in init_available_charsets ()
#3  0x00007f6387b26d33 in pthread_once () from /lib64/libpthread.so.0
#4  0x000000000072c621 in get_charset_by_csname ()
#5  0x0000000000712214 in mysql_init_character_set ()
#6  0x000000000071287f in mysql_real_connect ()

How to repeat:
Attempt to open several connection from several threads. It is not reproduced every time, but my application is crash-critical (run on production environment) and behavior like this unallowable.

Related bug: https://bugs.mysql.com/bug.php?id=62007

Thank you for the bug report. Please provide a test case code. Thanks.

Hello Miguel!

I am not the original bug reporter, but I can reproduce the problem.

Here is my way to do this:

1) Take recent mysql-5.5 server source tree.
2) Apply patch attached (bug76886.patch)
   This patch only adds one sleep to libmysql code which makes bug much
   more probable and adds tests/thread_test2 test.
3) Build non-debug server and thread_test2 test (debug version aborts
   with different stack-trace). 
4) Start server, for example by using ./mtr --mem --start-and-exit
5) You might have to edit tests/thread_test2.c to use proper path to socket file
   reported by step 4) (but it works without edits for me).
6) cd tests; ./thread_test2
7) Observe crash with the following stack-trace (assuming non-debug build)

 (gdb) bt
#0  0x0000000000418213 in my_stat ()
#1  0x0000000000415f27 in my_read_charset_file ()
#2  0x000000000041695f in init_available_charsets ()
#3  0x00007ffff7bc9a90 in pthread_once () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:103
#4  0x00000000004171ee in get_charset_by_csname ()
#5  0x00000000004055e8 in mysql_init_character_set ()
#6  0x00000000004066ac in mysql_real_connect ()
#7  0x0000000000402e80 in test_thread ()
#8  0x00007ffff7bc4182 in start_thread (arg=0x7ffff6aeb700) at pthread_create.c:312
#9  0x00007ffff73e747d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Now the problem with the thread_test2.c, of course, is that it doesn't call 
mysql_library_init() before starting threads which try to connect to server,
as it is described in the manual
(see http://dev.mysql.com/doc/refman/5.5/en/c-api-threaded-clients.html).

So one can say that problems are expected in this case.

Still apparently it is pretty common way (even though formally incorrect) to write multi-threaded application which tries to connect to MySQL Server

Patch with test case + probability tweak for this bug.

Attachment: bug76886.patch (text/x-patch), 3.57 KiB.

Thank you Dmitry, for confirming and providing patch/test case for the bug.
Marking as verified.

Thanks,
Umesh