Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
6.2.4
-
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.