Bug #58915 Valgrind warning in MYSQLparse()
Submitted: 14 Dec 2010 10:01 Modified: 24 Mar 2011 22:31
Reporter: Alexander Nozdrin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: General Severity:S1 (Critical)
Version:5.6 OS:Any
Assigned to: Magne Mæhre CPU Architecture:Any

[14 Dec 2010 10:01] Alexander Nozdrin
Description:
Several replication tests (rpl.rpl_change_master, in particular)
produce the following warnings being run under valgrind 3.5.0:

==9440== 256 bytes in 2 blocks are definitely lost in loss record 89 of 127
==9440==    at 0x4C20E1C: malloc (vg_replace_malloc.c:195)
==9440==    by 0x901014: my_malloc (my_malloc.c:38)
==9440==    by 0x8DDE48: init_dynamic_array2 (array.c:70)
==9440==    by 0x6DE93F: MYSQLparse(void*) (sql_yacc.yy:1881)
==9440==    by 0x5D4DA9: parse_sql(THD*, Parser_state*, Object_creation_ctx*) (sql_parse.cc:7265)
==9440==    by 0x5DED2D: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5492)
==9440==    by 0x5E0073: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1075)
==9440==    by 0x5E1544: do_command(THD*) (sql_parse.cc:815)
==9440==    by 0x6B1B24: do_handle_one_connection(THD*) (sql_connect.cc:745)
==9440==    by 0x6B1C20: handle_one_connection (sql_connect.cc:684)
==9440==    by 0x93B4BB: pfs_spawn_thread (pfs.cc:1360)
==9440==    by 0x4E2B73C: start_thread (in /lib64/libpthread-2.5.so)
==9440==    by 0x59DBD1C: clone (in /lib64/libc-2.5.so)

How to repeat:
Log:
http://pb2.norway.sun.com/web.py?action=archive_download&archive_id=2662212&pretty=please

Firstly noticed in the 'tor.didriksen@or... 2010-12-13 21:06:48' build
in daily-trunk-bugfixing.
[19 Jan 2011 9:37] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/129151

3527 Magne Mahre	2011-01-19
      Bug#58915 Valgrind warning in MYSQLparse()
      
      Under execution of a CHANGE MASTER command,
      a dynamic array (lex.bi.repl_ignore_server_ids)
      in the LEX replication information structure is
      allocated.
      
      Under normal operation, this array was deallocated
      at the end of execution (end of change_master() ).
      Certain error conditions (most notable if the 
      client thread is killed) would abort the execution
      before change_master() is called, resulting in
      memory block being lost.
      
      The deallocation has been moved to 
      THD::cleanup_after_query() to ensure that correct
      deallocation happens in all situations.
     @ sql/rpl_slave.cc
        Moved deallocation to THD::cleanup_after_query
     @ sql/sql_class.cc
        Moved cleanup code here (from change_master())
     @ sql/sql_lex.cc
        Initialize replication information structure
        to a known (0) value.
[3 Feb 2011 10:13] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/130307

3596 Magne Mahre	2011-02-03
      Bug#58915 Valgrind warning in MYSQLparse()
      
      Under execution of a CHANGE MASTER command,
      a dynamic array (lex.bi.repl_ignore_server_ids)
      in the LEX replication information structure is
      allocated.
      
      Under normal operation, this array was deallocated
      at the end of execution (end of change_master() ).
      Certain error conditions (most notable if the 
      client thread is killed) would abort the execution
      before change_master() is called, resulting in
      memory block being lost.
      
      The deallocation has been moved to 
      THD::cleanup_after_query() to ensure that correct
      deallocation happens in all situations.
     @ sql/rpl_slave.cc
        Moved deallocation to THD::cleanup_after_query
     @ sql/sql_class.cc
        Moved cleanup code here (from change_master())
     @ sql/sql_lex.cc
        Initialize replication information structure
        to a known (0) value.
[3 Feb 2011 10:13] Bugs System
Pushed into mysql-trunk 5.6.2 (revid:magne.mahre@oracle.com-20110203101306-q8auashb3d7icxho) (version source revid:magne.mahre@oracle.com-20110203101306-q8auashb3d7icxho) (merge vers: 5.6.2) (pib:24)
[24 Mar 2011 22:31] Paul DuBois
Problem not present in any released version. No changelog entry needed.

CHANGESET - http://lists.mysql.com/commits/130307