[MXS-3955] Crash after unexpected result Created: 2022-01-20  Updated: 2022-02-18  Resolved: 2022-02-04

Status: Closed
Project: MariaDB MaxScale
Component/s: Core, readwritesplit
Affects Version/s: 6.2.1
Fix Version/s: 6.2.2

Type: Bug Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 1
Labels: None
Environment:

MySQL 5.7

Sprint: MXS-SPRINT-150

 Description   

MaxScale crashes with the following stacktrace after an unexpected result is received.

  /lib64/libc.so.6(cfree+0x1c): :?
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale7Backend9ack_writeEv+0x4c): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/deque.tcc:568
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale7Backend5closeENS0_10close_typeE+0x48): server/core/backend.cc:51
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSessionD1Ev+0x71): server/modules/routing/readwritesplit/rwsplitsession.cc:82
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSessionD0Ev+0x11): server/modules/routing/readwritesplit/rwsplitsession.cc:91
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN15ServiceEndpoint5closeEv+0x7a): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/stl_iterator.h:780
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN9ClientDCB8shutdownEv+0x21): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/unique_ptr.h:147
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN3DCB7destroyEv+0x45): server/core/dcb.cc:789
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale13RoutingWorker14delete_zombiesEv+0x61): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/stl_vector.h:760
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale13RoutingWorker10epoll_tickEv+0x1d): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/stl_iterator.h:780
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x2b0): maxutils/maxbase/src/worker.cc:787
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x4f): maxutils/maxbase/src/worker.cc:565
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0x2dddff): thread48.o:?
 
  /lib64/libpthread.so.0(+0x7ea5): pthread_create.c:?
 
  /lib64/libc.so.6(clone+0x6d): ??:?

This appears to happen when there is a mismatch between the connection capabilities of the client and the backend server. In MaxScale 6.2.1 this can happen if:

  • MaxScale is used with MySQL 5.6
  • MaxScale is used with MySQL 5.7 that has the query cache enabled
  • Persistent connections are being used and the clients do not use a uniform set of capabilities (i.e. they use different connectors or connector versions)

 Comments   
Comment by markus makela [ 2022-01-24 ]

Managed to reproduce this using an older version: with a MySQL 5.6 server MaxScale would still advertise the deprecate_eof capability even though it was added in MySQL 5.7.

Comment by markus makela [ 2022-02-02 ]

Could theoretically be caused by https://bugs.mysql.com/bug.php?id=83346 but I've yet to be able to reproduce that, even with 5.7.15.

Comment by markus makela [ 2022-02-02 ]

Confirmed that this is indeed possible with both MySQL and Percona 5.7 versions, even the latest releases.

Comment by markus makela [ 2022-02-02 ]

Also found out that this can be caused by persistent connections that are shared between clients that have incompatible connection capabilities.

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