[MXS-2732] Memory leak with QC Created: 2019-10-26  Updated: 2019-11-01  Resolved: 2019-11-01

Status: Closed
Project: MariaDB MaxScale
Component/s: qc_sqlite
Affects Version/s: 2.3.12
Fix Version/s: 2.3.14, 2.4.3

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

Attachments: PNG File image-2019-10-27-07-41-18-188.png    
Sprint: MXS-SPRINT-93

 Description   

SQL:

CREATE VIEW v1 AS select sql_no_cache T0001.SERVERNAME AS SERVERNAME, T0003.TABNAME AS TABNAME,T0003.LOCAL_NAME AS LOCAL_NAME,T0002.DBINSTANCE AS DBINSTANCE from t2 T0001 join t1 T0002 join t3 T0003 where ((T0002.SERVERGRP = T0001.SERVERGRP) and (T0002.SERVERGRP = T0003.SERVERGRP) and (T0003.MAPSTATE = _latin1'A') and (T0003.ACTSTATE = _latin1' '))

stack:

 Comments   
Comment by markus makela [ 2019-10-27 ]

Oddly enough, I get a similar leak with invalid SQL (notice the unbalanced parentheses):

MariaDB [test]> create table t1 as select t1.id, t2.id, t3.id from t2 join t1 join t3 where ((t2.id = t1.id) and (t2.id = t3.id);
 
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1


==5608== 1,264 (80 direct, 1,184 indirect) bytes in 1 blocks are definitely lost in loss record 1,201 of 1,299
 
==5608==    at 0x483880B: malloc (vg_replace_malloc.c:309)
 
==5608==    by 0x689B2B5: sqlite3MemMalloc (sqlite3.c:18659)
 
==5608==    by 0x689B87D: sqlite3Malloc (sqlite3.c:22362)
 
==5608==    by 0x689BF3F: dbMallocRawFinish (sqlite3.c:22685)
 
==5608==    by 0x689C0BA: sqlite3DbMallocRawNN (sqlite3.c:22753)
 
==5608==    by 0x68DF65D: sqlite3ExprAlloc (sqlite3.c:87179)
 
==5608==    by 0x68DFA98: sqlite3ExprAnd (sqlite3.c:87325)
 
==5608==    by 0x68DF8D9: sqlite3PExpr (sqlite3.c:87269)
 
==5608==    by 0x6921A83: spanBinaryExpr (sqlite3.c:128548)
 
==5608==    by 0x692508D: yy_reduce (sqlite3.c:132836)
 
==5608==    by 0x6928463: sqlite3Parser (sqlite3.c:134380)
 
==5608==    by 0x6929946: sqlite3RunParser (sqlite3.c:135687)

If the SQL is corrected, the leak goes away.

Comment by Johan Wikman [ 2019-10-29 ]

There are two problems here.

  1. The MaxScale modified sqlite parser does not recognize _latin1'A' as a string, which causes the parsing of the statement to fail.
  2. In some cases, a failure to parse a statement leads to a memory leak.

The latter example causes a leak with the sqlite3 version used in MaxScale, but not e.g. with the sqlite3 release of my Ubuntu.

Comment by Johan Wikman [ 2019-11-01 ]

The parser of MaxScale has now been enhanced so that it will recognize _charset_name'string', for instance, _latin1' ' as a string.

In this case, it means that the example statement will be fully parsed and hence the sqlite3 leak will not occur.

However, the actual sqlite3 bug - a failure to parse a statement should not cause a leak - has not been fixed.

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