[MXS-4080] Query Cache detects wrong parse error in INSERT or DELETE Created: 2022-04-06  Updated: 2022-05-23  Resolved: 2022-04-07

Status: Closed
Project: MariaDB MaxScale
Component/s: cache
Affects Version/s: 6.2.4
Fix Version/s: 6.3.0

Type: Bug Priority: Major
Reporter: Philip Hoyer Assignee: Johan Wikman
Resolution: Fixed Votes: 0
Labels: None


 Description   

The query cache component sometimes detects a parse error in an INSERT or DELETE statement, however the query is valid.

2022-04-06 13:46:45   info   : (1) > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 57, type: QUERY_TYPE_WRITE, stmt: DELETE FROM `obj_stat_log_seq` WHERE sequence < 6000 
2022-04-06 13:46:45   notice : (1) [cache] (Read-Write-Service); UPDATE/DELETE/INSERT statement could not be parsed.The option clear_cache_on_parse_errors is true, the cache will be cleared.
 
2022-04-06 13:46:45   notice : (1) [cache] (Read-Write-Service); IGNORE, "DELETE FROM `obj_stat_log_seq` WHERE ...", statement is not SELECT.


2022-04-06 13:47:02   info   : (1) > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 60, type: QUERY_TYPE_WRITE, stmt: INSERT INTO `obj_stat_log_seq` (sequence) VALUES (NULL) 
2022-04-06 13:47:02   notice : (1) [cache] (Read-Write-Service); UPDATE/DELETE/INSERT statement could not be parsed.The option clear_cache_on_parse_errors is true, the cache will be cleared.
 
2022-04-06 13:47:02   notice : (1) [cache] (Read-Write-Service); IGNORE, "INSERT INTO `obj_stat_log_seq` (seque...", statement is not SELECT.

In consequence the cache will be cleared. But it seems the cache is not cleared properly, because on the next query MaxScale will crash.

alert  : MaxScale 6.2.4 received fatal signal 11. Commit ID: 6e1317be296490366b7bf11b8e9b1864acc365d6 System name: Linux Release string: undefined
 
 
 
 
 
2022-04-06 13:47:06   alert  : (1) (Read-Write-Service); MaxScale 6.2.4 received fatal signal 11. Commit ID: 6e1317be296490366b7bf11b8e9b1864acc365d6 System name: Linux Release string: undefined
 
2022-04-06 13:47:06   alert  : (1) (Read-Write-Service); Statement currently being classified: none/unknown
 
2022-04-06 13:47:06   alert  : (1) (Read-Write-Service); DCB: 0x7ff58c0163f0 Session: 1 Service: Read-Write-Service
 
2022-04-06 13:47:06   notice : (1) (Read-Write-Service); For a more detailed stacktrace, install GDB and add 'debug=gdb-stacktrace' under the [maxscale] section.
 
nm: /lib/x86_64-linux-gnu/libstdc++.so.6: no symbols
 
nm: /lib/x86_64-linux-gnu/libc.so.6: no symbols
 
  /lib/x86_64-linux-gnu/libstdc++.so.6(_ZSt11_Hash_bytesPKvmm+0x28): ??:0
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZNSt8__detail9_Map_baseINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS6_St13unordered_setIPN10LRUStorage4NodeESt4hashISC_ESt8equal_toISC_ESaISC_EEESaISJ_ENS_10_Select1stESF_IS6_ESD_IS6_ENS_18_Mod_range_hashingENS_20_Default_ranged_hashENS_20_Prime_rehash_policyENS_17_Hashtable_traitsILb1ELb0ELb1EEELb1EEixERS8_+0x28): /usr/include/c++/10/bits/hashtable_policy.h:433
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZN10LRUStorage14LRUInvalidator11remove_noteEPNS_4NodeERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS9_EE+0x3b): /usr/include/c++/10/bits/hashtable_policy.h:433
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZNK10LRUStorage9free_nodeEPNS_4NodeENS_17InvalidatorActionE+0x25): server/modules/filter/cache/lrustorage.cc:840
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZNK10LRUStorage9free_nodeERNSt8__detail14_Node_iteratorISt4pairIK8CacheKeyPNS_4NodeEELb0ELb1EEENS_17InvalidatorActionE+0x19): server/modules/filter/cache/lrustorage.cc:856
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZN10LRUStorage12access_valueENS_17access_approach_tERK8CacheKeyjjjPP5GWBUF+0xf6): server/modules/filter/cache/lrustorage.cc:686
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZN12LRUStorageMT9get_valueEPN7Storage5TokenERK8CacheKeyjjjPP5GWBUFRKSt8functionIFvjS7_EE+0x64): server/modules/filter/cache/lrustoragemt.cc:54
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZN18CacheFilterSession12route_SELECTENS_14cache_action_tERK10CacheRulesP5GWBUF+0x157): server/modules/filter/cache/sessioncache.hh:88
 
  /usr/lib/x86_64-linux-gnu/maxscale/libcache.so(_ZN18CacheFilterSession10routeQueryEP5GWBUF+0x2e9): server/modules/filter/cache/cachefiltersession.cc:439
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN15ServiceEndpoint10routeQueryEP5GWBUF+0x85): server/core/service.cc:1694
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN7Session10routeQueryEP5GWBUF+0x31): server/core/session.cc:1193
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN23MariaDBClientConnection21process_normal_packetEON8maxscale6BufferE+0x133): server/modules/protocol/MariaDB/mariadb_client.cc:2764
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN23MariaDBClientConnection19process_normal_readEv+0x3f4): server/modules/protocol/MariaDB/mariadb_client.cc:1396
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN23MariaDBClientConnection17ready_for_readingEP3DCB+0x88): server/modules/protocol/MariaDB/mariadb_client.cc:1548
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN3DCB14process_eventsEj+0xc4): server/core/dcb.cc:1334
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN3DCB13event_handlerEPS_j+0x21): server/core/dcb.cc:1370
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x212): maxutils/maxbase/src/worker.cc:865
 
  /usr/lib/x86_64-linux-gnu/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x4f): maxutils/maxbase/src/worker.cc:566
 
  /lib/x86_64-linux-gnu/libstdc++.so.6(+0xceed0): ??:?
 
  /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7): ??:?
 
  /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f): ??:0
 
alert  : Writing core dump.

Setting the option "clear_cache_on_parse_errors" to false will prevent the crash.

But it seems to me that there are two bugs:

  • The given INSERT/DELETE statement should not be classified as a parse error.
  • After the cache is cleared due to a parse error, MaxScale should not crash.

 Comments   
Comment by markus makela [ 2022-04-06 ]

Does adding backticks around the sequence word help? There's probably some keyword that's conflicting with it.

As for the crash, it's possibly caused by the failure to parse but that should not cause a crash.

Comment by Philip Hoyer [ 2022-04-06 ]

Does adding backticks around the sequence word help?

Yes, it does indeed. Thanks for the hint!

2022-04-06 19:18:12   info   : (5) > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 62, type: QUERY_TYPE_WRITE, stmt: INSERT INTO `obj_stat_log_seq` (`sequence`) VALUES (NULL) 
2022-04-06 19:18:12   notice : (5) [cache] (Read-Write-Service); IGNORE, "INSERT INTO `obj_stat_log_seq` (`sequ...", statement is not SELECT.
 
2022-04-06 19:18:12   info   : (5) (Read-Write-Service); > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 62, type: QUERY_TYPE_WRITE, stmt: INSERT INTO `obj_stat_log_seq` (`sequence`) VALUES (NULL) 
2022-04-06 19:18:12   notice : (5) [cache] (Read-Write-Service); Cache successfully invalidated.
 
 
 
2022-04-06 19:18:12   info   : (5) > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 59, type: QUERY_TYPE_WRITE, stmt: DELETE FROM `obj_stat_log_seq` WHERE `sequence` < 5701 
2022-04-06 19:18:12   notice : (5) [cache] (Read-Write-Service); IGNORE, "DELETE FROM `obj_stat_log_seq` WHERE ...", statement is not SELECT.
 
2022-04-06 19:18:12   info   : (5) (Read-Write-Service); > Autocommit: [enabled], trx is [not open], cmd: (0x03) COM_QUERY, plen: 59, type: QUERY_TYPE_WRITE, stmt: DELETE FROM `obj_stat_log_seq` WHERE `sequence` < 5701 
2022-04-06 19:18:12   notice : (5) [cache] (Read-Write-Service); Cache successfully invalidated.

Comment by markus makela [ 2022-04-06 ]

OK, this suggests that the problem is with the SEQUENCE keyword not being interpreted as an identifier when it fails to otherwise parse as a SQL keyword.

Comment by Johan Wikman [ 2022-04-07 ]

There were two problems

  • The failure to parse the statement correctly.
  • The crash when clearing the cache.

Both have now been fixed.

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