[MXS-3414] maxscale auto-restarts after fatal signal 11 Created: 2021-02-23  Updated: 2021-03-25  Resolved: 2021-03-02

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: 2.4.16
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Allen Lee (Inactive) Assignee: markus makela
Resolution: Duplicate Votes: 0
Labels: None
Environment:

physical server, onpremise, CentOS


 Description   

maxscale auto-restarts after fatal signal 11.

Initially with MaxScale 2.4.10, it threw the following error with maxscale v2.4.10.

2021-02-16 10:25:48 error : (47311) Write to Client DCB ::ffff:10.0.50.99 in state DCB_STATE_POLLING failed: 104, Connection reset by peer
 
....
 
2021-02-16 10:26:30 alert : Fatal: MaxScale 2.4.10 received fatal signal 6. Commit ID: 7781f7042ab077811e2431794c2280162c0a6a3d System name: Linux Release string: NAME="CentOS Linux"
 
...
 
2021-02-16 10:27:33 alert :
 
/lib64/libc.so.6(epoll_wait+0x33): :?
 
/usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0xd0): maxutils/maxbase/src/worker.cc:795
 
/usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x53): maxutils/maxbase/src/worker.cc:559
 
/usr/bin/maxscale(main+0x2aa1): server/core/gateway.cc:2273
 
/lib64/libc.so.6(__libc_start_main+0xf5): ??:?
 
/usr/bin/maxscale(): ??:?

And found MXS-3220, which might be the fix for this. But, after upgrading to v2.4.13, user hit the following:

2021-02-20 23:46:20   alert  : (3673316) Fatal: MaxScale 2.4.13 received fatal signal 11. Commit ID: faaf7f483eeb7afd75a5ca08fa258fae0d8c1456 System name: Linux Release string: NAME="CentOS Linux"
 
...
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale7Session9QueryInfo20book_server_responseEP6SERVERb+0x45): /opt/rh/devtoolset-7/root/usr/include/c++/7/ext/new_allocator.h:136
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale7Session20book_server_responseEP6SERVERb+0xfe): server/core/session.cc:1499
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN14RWSplitSession11clientReplyEP5GWBUFP3DCB+0x982): maxutils/maxbase/include/maxbase/log.h:168
 
  /usr/lib64/maxscale/libreadwritesplit.so(_ZN8maxscale6RouterI7RWSplit14RWSplitSessionE11clientReplyEP10mxs_routerP18mxs_router_sessionP5GWBUFP3DCB+0x27): include/maxscale/router.hh:477
 
  /usr/lib64/maxscale/libmariadbbackend.so(+0x5b7b): server/modules/protocol/MySQL/mariadbbackend/mysql_backend.cc:1066
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0xa14c2): server/core/dcb.cc:2705
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0xa1531): server/core/dcb.cc:2757
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x196): maxutils/maxbase/src/worker.cc:858
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x53): maxutils/maxbase/src/worker.cc:559
 
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0x1b80cf): thread48.o:?
 
  /lib64/libpthread.so.0(+0x7ea5): pthread_create.c:?
 
  /lib64/libc.so.6(clone+0x6d): ??:?



 Comments   
Comment by markus makela [ 2021-02-23 ]

Looks like a duplicate of MXS-3330. Please test with the latest 2.4 release. The crash can be avoided in 2.4.13 by not using retain_last_statements.

Comment by markus makela [ 2021-03-02 ]

I'll close this as a duplicate as it's likely that this indeed was a duplicate of the aforementioned issue. I did, however, find a new bug with LOAD DATA LOCAL INFILE that is related to this (MXS-3425).

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