[MXS-3342] Persistent connections cause signal 11 when no matching connection is found Created: 2020-12-16  Updated: 2020-12-18  Resolved: 2020-12-17

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 2.5.6
Fix Version/s: 2.5.7

Type: Bug Priority: Major
Reporter: Tim Westervoorde Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS Linux release 7.8.2003 (Core)
Kernel 4.4.241-1.el7.elrepo.x86_64
mariadb Ver 15.1 Distrib 10.4.17-MariaDB, for Linux (x86_64) using readline 5.1
MaxScale 2.5.6 - fddc0526ee79ac9a87f7a7170f3204263240ab57


 Description    

2020-12-16 13:50:37   alert  : (24) (db3) MaxScale 2.5.6 received fatal signal 11. Commit ID: fddc0526ee79ac9a87f7a7170f3204263240ab57 System name: Linux Release string: NAME="CentOS Linux"
 
2020-12-16 13:50:37   alert  : (24) (db3) Statement currently being classified: none/unknown
 
2020-12-16 13:50:39   alert  : (24) (db3)
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale13RoutingWorker25get_backend_dcb_from_poolEP6SERVERP11MXS_SESSIONPNS_9ComponentE+0x200): server/core/routingworker.cc:568
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale13RoutingWorker15get_backend_dcbEP6SERVERP11MXS_SESSIONPNS_9ComponentE+0x91): server/core/routingworker.cc:530
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN14ServerEndpoint7connectEv+0x7d): server/core/server.cc:932 (discriminator 1)
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale7Backend7connectEPSt4listISt10shared_ptrINS_14SessionCommandEESaIS4_EE+0x1f): server/core/backend.cc:174
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSession18prepare_connectionEPN8maxscale9RWBackendE+0x19): server/modules/routing/readwritesplit/rwsplit_route_stmt.cc:48
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSession16open_connectionsEv+0x5a4): server/modules/routing/readwritesplit/rwsplit_select_backends.cc:463
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSession6createEP7RWSplitP11MXS_SESSIONRKSt6vectorIPN8maxscale8EndpointESaIS7_EE+0x131): server/modules/routing/readwritesplit/rwsplitsession.cc:67
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN8maxscale6RouterI7RWSplit14RWSplitSessionE10newSessionEP10mxs_routerP11MXS_SESSIONPNS_8UpstreamERKSt6vectorIPNS_8EndpointESaISC_EE+0x14): include/maxscale/router.hh:404
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN15ServiceEndpoint7connectEv+0x10d): server/core/service.cc:1291
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7Session5startEv+0x21): server/core/session.cc:1283
 
  /usr/lib64/maxscale/libmariadbclient.so(_ZN23MariaDBClientConnection22process_authenticationENS_8AuthTypeE+0x319): server/modules/protocol/MariaDB/mariadb_client.cc:615
 
  /usr/lib64/maxscale/libmariadbclient.so(_ZN23MariaDBClientConnection17ready_for_readingEP3DCB+0x39): server/modules/protocol/MariaDB/mariadb_client.cc:1418
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN3DCB14process_eventsEj+0x69): server/core/dcb.cc:1292
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN3DCB13event_handlerEPS_j+0x21): server/core/dcb.cc:1351
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x1be): maxutils/maxbase/src/worker.cc:879
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x53): maxutils/maxbase/src/worker.cc:574
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0x228a0f): thread48.o:?
 
  /lib64/libpthread.so.0(+0x7ea5): pthread_create.c:?
 
  /lib64/libc.so.6(clone+0x6d): ??:?



 Comments   
Comment by Tim Westervoorde [ 2020-12-16 ]

This seems related to persistent connections and commit aa830af47a53adacca02952a8caf4505750d742f, MXS-3328: Use DCBs from same IP with proxy_protocol

There is no guarantee that the persistent pool has a connection which matches our host so pDcb can be null after the for loop. This condition is not checked.

Comment by Tim Westervoorde [ 2020-12-16 ]

I think this has an easy fix, see pull request

https://github.com/mariadb-corporation/MaxScale/pull/218

Comment by markus makela [ 2020-12-16 ]

That's a very obvious bug now that I look at it. For now I'd recommend disabling the persistent connection pool to prevent this from happening.

Comment by Tim Westervoorde [ 2020-12-16 ]

I did and seems to work fine with persistent connections disabled.

Comment by markus makela [ 2020-12-16 ]

Thank you for your pull request!

Generated at Thu Feb 08 04:20:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.