[CONPY-144] ConnectionPool segmentation fault, ping Created: 2021-02-28  Updated: 2021-03-11  Resolved: 2021-03-10

Status: Closed
Project: MariaDB Connector/Python
Component/s: Generic
Affects Version/s: 1.0.5, 1.0.6
Fix Version/s: 1.0.7

Type: Bug Priority: Critical
Reporter: Lee Clemens Assignee: Georg Richter
Resolution: Fixed Votes: 0
Labels: SEGV
Environment:

CentOS 7
MariaDB 10.5.9
Python 3.8.1 / 3.9.1
mariadb 1.0.5 / 1.0.6


 Description   

Hello,

While I am using the python connector, it may not be the best Project to file this under. Please let me know if I should file it somewhere else or move it as necessary.

I am seeing segfaults after 1-2 iterations of fetching connections from a ConnectionPool. It happens after the third connection is re-fetched from the pool most of the time (excluding pool_size=1).

I originally thought it was due to my call to .ping(), but it is reproducible without explicitly calling ping() in the test code below (seems to be same stack, I believe ping is called internally regardless).

Server
 
CentOS 7
 
3.10.0-1160.15.2.el7.x86_64
 
MariaDB-server-10.5.9-1.el7.centos.x86_64


Client
 
CentOS 7
 
3.10.0-1160.15.2.el7.x86_64
 
 
 
# rpm -qa | grep -i maria | sort
 
MariaDB-client-10.5.9-1.el7.centos.x86_64
 
MariaDB-client-debuginfo-10.5.9-1.el7.centos.x86_64
 
MariaDB-common-10.5.9-1.el7.centos.x86_64
 
MariaDB-common-debuginfo-10.5.9-1.el7.centos.x86_64
 
MariaDB-compat-10.5.9-1.el7.centos.x86_64
 
MariaDB-connect-engine-debuginfo-10.5.9-1.el7.centos.x86_64
 
MariaDB-devel-10.5.9-1.el7.centos.x86_64
 
MariaDB-devel-debuginfo-10.5.9-1.el7.centos.x86_64
 
MariaDB-shared-10.5.9-1.el7.centos.x86_64
 
MariaDB-shared-debuginfo-10.5.9-1.el7.centos.x86_64


Python 3.8.1
 
Python 3.9.1
 
 
 
mariadb 1.0.6

Both Python versions segfault from the same line:
/usr/src/debug/MariaDB-/src_0/libmariadb/libmariadb/ma_net.c:148

https://gist.github.com/leeclemens/0795d957588410f69fc0a6453ecec94f

If the pool_size is > 1, it seems to occur during the pool_size + 3 loop (see comment in gist).

Starting program: /u01/python/v381/bin/python test_segfault_ping.py
 
[Thread debugging using libthread_db enabled]
 
Using host libthread_db library "/lib64/libthread_db.so.1".
 
[Detaching after fork from child process 1735]
 
[New Thread 0x7fffe74cc700 (LWP 1736)]
 
[New Thread 0x7fffe6871700 (LWP 1737)]
 
PingThread running
 
starting loop 1
 
    sleeping after 1 get of 3 conns
 
starting loop 2
 
    sleeping after 2 get of 3 conns
 
starting loop 3
 
    sleeping after 3 get of 3 conns
 
starting loop 4
 
    sleeping after 4 get of 3 conns
 
starting loop 5
 
    sleeping after 5 get of 3 conns
 
starting loop 6
 
 
 
Program received signal SIGSEGV, Segmentation fault.
 
[Switching to Thread 0x7fffe6871700 (LWP 1737)]
 
ma_net_clear (net=net@entry=0xdb0a80) at /usr/src/debug/MariaDB-/src_0/libmariadb/libmariadb/ma_net.c:148
 
148	  if (net->extension->multi_status > COM_MULTI_OFF)
 
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 glibc-2.17-323.el7_9.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-50.el7.x86_64 libcom_err-1.42.9-19.el7.x86_64 libffi-3.0.13-19.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libselinux-2.5-15.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64 libuuid-2.23.2-65.el7_9.1.x86_64 nss-softokn-freebl-3.53.1-6.el7_9.x86_64 openssl-libs-1.0.2k-21.el7_9.x86_64 pcre-8.32-17.el7.x86_64 xz-libs-5.2.2-1.el7.x86_64 zlib-1.2.7-19.el7_9.x86_64


(gdb) bt
 
#0  ma_net_clear (net=net@entry=0xdb0a80) at /usr/src/debug/MariaDB-/src_0/libmariadb/libmariadb/ma_net.c:148
 
#1  0x00007ffff0087901 in mthd_my_send_cmd (mysql=0xdb0a80, command=COM_PING, arg=0x0, length=0, skipp_check=<optimized out>, opt_arg=<optimized out>)
 
    at /usr/src/debug/MariaDB-/src_0/libmariadb/libmariadb/mariadb_lib.c:393
 
#2  0x00007ffff0087d20 in mysql_ping (mysql=0xdb0a80) at /usr/src/debug/MariaDB-/src_0/libmariadb/libmariadb/mariadb_lib.c:2792
 
#3  0x00007ffff02d8b60 in MrdbPool_getconnection (self=0x7fffe74f9940) at mariadb/mariadb_pooling.c:346
 
#4  0x000000000059a743 in method_vectorcall_NOARGS () at Objects/descrobject.c:393
 
#5  0x000000000053ce8b in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=<optimized out>, callable=0x7fffedc9a900) at ./Include/cpython/abstract.h:127
 
#6  call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0xbdd310) at Python/ceval.c:4987
 
#7  _PyEval_EvalFrameDefault () at Python/ceval.c:3486
 
#8  0x00000000004cf442 in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>, co=<optimized out>) at Objects/call.c:283
 
#9  _PyFunction_Vectorcall () at Objects/call.c:410
 
#10 0x000000000053ce8b in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=<optimized out>, callable=0x7fffe6ca3820) at ./Include/cpython/abstract.h:127
 
#11 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0xbdd310) at Python/ceval.c:4987
 
#12 _PyEval_EvalFrameDefault () at Python/ceval.c:3486
 
#13 0x00000000004cf442 in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>, co=<optimized out>) at Objects/call.c:283
 
#14 _PyFunction_Vectorcall () at Objects/call.c:410
 
#15 0x000000000053ce8b in _PyObject_Vectorcall (kwnames=0x0, nargsf=<optimized out>, args=<optimized out>, callable=0x7ffff05633a0) at ./Include/cpython/abstract.h:127
 
#16 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0xbdd310) at Python/ceval.c:4987
 
#17 _PyEval_EvalFrameDefault () at Python/ceval.c:3486
 
#18 0x00000000004cf442 in function_code_fastcall (globals=<optimized out>, nargs=1, args=<optimized out>, co=<optimized out>) at Objects/call.c:283
 
#19 _PyFunction_Vectorcall () at Objects/call.c:410
 
#20 0x0000000000597309 in _PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>) at ./Include/cpython/abstract.h:127
 
#21 method_vectorcall () at Objects/classobject.c:67
 
#22 0x00000000004d10de in PyVectorcall_Call (kwargs=0x0, tuple=0x7ffff7fa8040, callable=0x7ffff7f99380) at Objects/call.c:199
 
#23 PyObject_Call () at Objects/call.c:227
 
#24 0x00000000005f4cd5 in t_bootstrap () at ./Modules/_threadmodule.c:1002
 
#25 0x00000000005def64 in pythread_wrapper (arg=<optimized out>) at Python/thread_pthread.h:232
 
#26 0x00007ffff798fea5 in start_thread () from /lib64/libpthread.so.0
 
#27 0x00007ffff6faf9fd in clone () from /lib64/libc.so.6



 Comments   
Comment by Georg Richter [ 2021-03-10 ]

Fied in rev. fdee5137d547fc845441233125cc8b31dcea8e23

Comment by Lee Clemens [ 2021-03-11 ]

This looks good, thanks! I see the version number was bumped, but does the tag need to be pushed as well to generate a new release?

Comment by Georg Richter [ 2021-03-11 ]

No, tag will be added before releasing. Usually the version number will be bumped after each release - In this case I bumped it, but forgot to commit it (instead it was committed together with this fix).

Generated at Thu Feb 08 03:30:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.