[MXS-3954] Got below signal 11 error after upgrading maxscale version maxscale 6.2.1 Created: 2022-01-20  Updated: 2023-10-27  Resolved: 2022-02-18

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 2.5, 6
Fix Version/s: 2.5.20, 6.2.3

Type: Bug Priority: Critical
Reporter: Pon Suresh Pandian (Inactive) Assignee: Johan Wikman
Resolution: Fixed Votes: 1
Labels: None
Environment:

CentOS 7


Attachments: File maxscale_6.2.1_error_log    
Issue Links:
Problem/Incident
is caused by MXS-4001 The Cache filter cannot cope with the... Closed
Sprint: MXS-SPRINT-150, MXS-SPRINT-151

 Description   

Hi Team,

Got below signal 11 error after upgrading maxscale version from 6.1.4 to maxscale 6.2.1.

alert  : MaxScale 6.2.1 received fatal signal 11. Commit ID: 384129e62d4af72509b6640542eb5ee277304f26 System name: Linux Release string: NAME="CentOS Linux"
 
 
 
 
 
2022-01-19 23:08:34   alert  : MaxScale 6.2.1 received fatal signal 11. Commit ID: 384129e62d4af72509b6640542eb5ee277304f26 System name: Linux Release string: NAME="CentOS Linux"
 
2022-01-19 23:08:34   alert  : Statement currently being classified: none/unknown
 
2022-01-19 23:08:34   notice : For a more detailed stacktrace, install GDB and add 'debug=gdb-stacktrace' under the [maxscale] section.
 
  /usr/lib64/maxscale/libstorage_redis.so(_ZN12RedisStorage5clearEPN7Storage5TokenE+0x6f): server/modules/filter/cache/storage/storage_redis/redisstorage.cc:323
 
  /usr/lib64/maxscale/libcache.so(_ZN18CacheFilterSession11clear_cacheEv+0x1d): server/modules/filter/cache/cachefiltersession.cc:474
 
  /usr/lib64/maxscale/libcache.so(+0x32174): server/modules/filter/cache/cachefiltersession.cc:548
 
  /usr/lib64/maxscale/libstorage_redis.so(+0x5c84): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/std_function.h:318
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker14handle_messageERNS_12MessageQueueERKNS_19MessageQueueMessageE+0x119): maxutils/maxbase/src/worker.cc:481
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase12MessageQueue18handle_poll_eventsEPNS_6WorkerEj+0x98): maxutils/maxbase/src/messagequeue.cc:307
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x221): maxutils/maxbase/src/worker.cc:856
 
  /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): ??:?
 
alert  : Writing core dump.

Here I have attached the maxscale log please check it.

 Comments   
Comment by Johan Wikman [ 2022-02-17 ]

This problem is not related to 6.2.1, but is present in 2.5 as well.

This is indirectly caused by MXS-4001, so this bug will only manifest itself if Redis has been configured with an idle timeout.
In that case, if there is no cache activity for a period longer than the Redis idle timeout, Redis will close the connection opened by MaxScale. If that has happened at a point when MaxScale decides to clear the cache, which it will decide to do if an attempt to delete a particular cache item fails, which will be the case if Redis has closed the connection, then MaxScale will crash because it does not properly take into account the possibility that the connection has been closed.

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