|
CREATE TRIGGER and CREATE PROCEDURE seem to cause the same behavior.
Query
CREATE TRIGGER trg2 AFTER DELETE ON t1 FOR EACH ROW INSERT INTO t1 VALUES (1);
|
|
Valgrind output
25,584 (8,224 direct, 17,360 indirect) bytes in 1 blocks are definitely lost in loss record 353 of 368
|
==31075== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
|
==31075== by 0x72D426: my_malloc (in /home/markus/build/bin/maxscale)
|
==31075== by 0x71941F: init_alloc_root (in /home/markus/build/bin/maxscale)
|
==31075== by 0x601BC4: init_sql_alloc(st_mem_root*, unsigned int, unsigned int, unsigned long) (in /home/markus/build/bin/maxscale)
|
==31075== by 0x5B2FD5: sp_head::operator new(unsigned long) (in /home/markus/build/bin/maxscale)
|
==31075== by 0x7FF35F: MYSQLparse(THD*) (in /home/markus/build/bin/maxscale)
|
==31075== by 0x6DC766: parse_sql(THD*, Parser_state*, Object_creation_ctx*, bool) (in /home/markus/build/bin/maxscale)
|
==31075== by 0x1C54271A: create_parse_tree(THD*) (query_classifier.cc:380)
|
==31075== by 0x1C542186: parse_query (query_classifier.cc:199)
|
==31075== by 0x1C541ED0: query_classifier_get_type (query_classifier.cc:110)
|
==31075== by 0x1C330A61: route_single_stmt (readwritesplit.c:2081)
|
==31075== by 0x1C3303FB: routeQuery (readwritesplit.c:1976)
|
==31075==
|
==31075== LEAK SUMMARY:
|
==31075== definitely lost: 8,256 bytes in 2 blocks
|
==31075== indirectly lost: 17,360 bytes in 9 blocks
|
==31075== possibly lost: 270,926,872 bytes in 211 blocks
|
==31075== still reachable: 1,279,273 bytes in 975 blocks
|
==31075== suppressed: 0 bytes in 0 blocks
|
==31075== Reachable blocks (those to which a pointer was found) are not shown.
|
==31075== To see them, add 'reachable any' args to leak_check
|
|
Query
CREATE PROCEDURE simpleproc (OUT param1 INT)
|
-> BEGIN
|
-> SELECT COUNT(*) INTO param1 FROM t1;
|
-> END//
|
|
Valgrind output
|
==31259== 26,464 (8,224 direct, 18,240 indirect) bytes in 1 blocks are definitely lost in loss record 360 of 375
|
==31259== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
|
==31259== by 0x72D426: my_malloc (in /home/markus/build/bin/maxscale)
|
==31259== by 0x71941F: init_alloc_root (in /home/markus/build/bin/maxscale)
|
==31259== by 0x601BC4: init_sql_alloc(st_mem_root*, unsigned int, unsigned int, unsigned long) (in /home/markus/build/bin/maxscale)
|
==31259== by 0x5B2FD5: sp_head::operator new(unsigned long) (in /home/markus/build/bin/maxscale)
|
==31259== by 0x7FFCD4: MYSQLparse(THD*) (in /home/markus/build/bin/maxscale)
|
==31259== by 0x6DC766: parse_sql(THD*, Parser_state*, Object_creation_ctx*, bool) (in /home/markus/build/bin/maxscale)
|
==31259== by 0x1C54271A: create_parse_tree(THD*) (query_classifier.cc:380)
|
==31259== by 0x1C542186: parse_query (query_classifier.cc:199)
|
==31259== by 0x1C541ED0: query_classifier_get_type (query_classifier.cc:110)
|
==31259== by 0x1C330A61: route_single_stmt (readwritesplit.c:2081)
|
==31259== by 0x1C3303FB: routeQuery (readwritesplit.c:1976)
|
==31259==
|
==31259== LEAK SUMMARY:
|
==31259== definitely lost: 8,256 bytes in 2 blocks
|
==31259== indirectly lost: 18,240 bytes in 15 blocks
|
==31259== possibly lost: 270,926,872 bytes in 211 blocks
|
==31259== still reachable: 1,279,305 bytes in 976 blocks
|
==31259== suppressed: 0 bytes in 0 blocks
|
==31259== Reachable blocks (those to which a pointer was found) are not shown.
|
==31259== To see them, add 'reachable any' args to leak_check
|
|
|
|
Doesn't look like a bug. A server explicitly releases this memory, it has
delete lex->sphead;
|
lex->sphead= NULL;
|
at the end of “create event" code. As you invoke the parser directly, you have to free this memory manually after every statement.
|