Bug #34424 query_cache_debug.test leads to valgrind warnings
Submitted: 8 Feb 2008 16:48 Modified: 16 Apr 2008 14:19
Reporter: Alexander Nozdrin Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.1, 6.0 OS:Any
Assigned to: Davi Arnaut CPU Architecture:Any

[8 Feb 2008 16:48] Alexander Nozdrin
Description:
The following sequence of test cases leads to new valgrind warnings:

> ./mysql-test-run.pl query_cache_debug select_safe

Warnings are:
==12891== 42 bytes in 1 blocks are indirectly lost in loss record 3 of 7
==12891==    at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==12891==    by 0x967A19: DbugMalloc (dbug.c:1997)
==12891==    by 0x968E34: ListAdd (dbug.c:1246)
==12891==    by 0x969360: _db_set_ (dbug.c:526)
==12891==    by 0x96978E: _db_push_ (dbug.c:697)
==12891==    by 0x64E493: sys_var_thd_dbug::update(THD*, set_var*) (set_var.cc:3831)
==12891==    by 0x644912: set_var::update(THD*) (set_var.cc:3289)
==12891==    by 0x64D16D: sql_set_variables(THD*, List<set_var_base>*) (set_var.cc:3175)
==12891==    by 0x641BCA: mysql_execute_command(THD*) (sql_parse.cc:3250)
==12891==    by 0x642170: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5630)
==12891==    by 0x642DB0: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1121)
==12891==    by 0x643C35: do_command(THD*) (sql_parse.cc:781)
==12891==    by 0x6351FB: handle_one_connection (sql_connect.cc:1120)
==12891==    by 0x4E2D01F: start_thread (in /lib64/libpthread-2.6.1.so)
==12891==    by 0x5BC2F8C: clone (in /lib64/libc-2.6.1.so)

==12891== 42 bytes in 1 blocks are indirectly lost in loss record 3 of 7
==12891==    at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==12891==    by 0x967A19: DbugMalloc (dbug.c:1997)
==12891==    by 0x968E34: ListAdd (dbug.c:1246)
==12891==    by 0x969360: _db_set_ (dbug.c:526)
==12891==    by 0x96978E: _db_push_ (dbug.c:697)
==12891==    by 0x64E493: sys_var_thd_dbug::update(THD*, set_var*) (set_var.cc:3831)
==12891==    by 0x644912: set_var::update(THD*) (set_var.cc:3289)
==12891==    by 0x64D16D: sql_set_variables(THD*, List<set_var_base>*) (set_var.cc:3175)
==12891==    by 0x641BCA: mysql_execute_command(THD*) (sql_parse.cc:3250)
==12891==    by 0x642170: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5630)
==12891==    by 0x642DB0: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1121)
==12891==    by 0x643C35: do_command(THD*) (sql_parse.cc:781)
==12891==    by 0x6351FB: handle_one_connection (sql_connect.cc:1120)
==12891==    by 0x4E2D01F: start_thread (in /lib64/libpthread-2.6.1.so)
==12891==    by 0x5BC2F8C: clone (in /lib64/libc-2.6.1.so)

That started to happen after patch for Bug#30887 pushed into 5.1-runtime
on 04-Jan-2008.
https://intranet.mysql.com/secure/pushbuild/showpush.pl?dir=mysql-5.1-runtime&order=617

How to repeat:
https://intranet.mysql.com/secure/pushbuild/showpush.pl?dir=mysql-5.1-runtime&order=617
[8 Feb 2008 17:05] 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/41955

ChangeSet@1.2540, 2008-02-08 20:07:39+03:00, anozdrin@quad. +1 -0
  Bug#34424: query_cache_debug.test leads to valgrind warnings
  
  Disable the test case.
[11 Feb 2008 13:26] Davi Arnaut
It seems that the debug session variable leaks, other tests using the session debug variables have:

--source include/not_valgrind.inc

But it would be nice to track down this leak, it's important to run this test case under valgrind.
[11 Feb 2008 16:24] Bugs System
Pushed into 5.1.24-rc
[11 Feb 2008 16:26] Bugs System
Pushed into 6.0.5-alpha
[13 Feb 2008 22:13] Omer Barnir
triage: valgrind
[18 Feb 2008 13:18] 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/42491

ChangeSet@1.2553, 2008-02-18 10:18:07-03:00, davi@mysql.com +4 -0
  Bug#34424 query_cache_debug.test leads to valgrind warnings
  
  The problem is that the per-thread debugging settings stack wasn't
  being deallocated before the thread termination, leaking the stack
  memory. The solution is to free the per-thread debugging settings
  stack once the thread finishes.
[25 Feb 2008 10:39] 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/42927

ChangeSet@1.2578, 2008-02-25 07:39:20-03:00, davi@mysql.com +7 -0
  Bug#34424 query_cache_debug.test leads to valgrind warnings
  Bug#34678 @@debug variable's incremental mode
  
  The problem is that the per-thread debugging settings stack wasn't
  being deallocated before the thread termination, leaking the stack
  memory. The chosen solution is to push a new state if the current
  is set to the initial settings and pop it (free) once the thread
  finishes.
[26 Feb 2008 15:05] 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/42996

ChangeSet@1.2580, 2008-02-26 12:03:59-03:00, davi@mysql.com +7 -0
  Bug#34424 query_cache_debug.test leads to valgrind warnings
  Bug#34678 @@debug variable's incremental mode
  
  The problem is that the per-thread debugging settings stack wasn't
  being deallocated before the thread termination, leaking the stack
  memory. The chosen solution is to push a new state if the current
  is set to the initial settings and pop it (free) once the thread
  finishes.
[26 Feb 2008 15:13] Davi Arnaut
Queued in 5.1-runtime
[3 Mar 2008 18:18] Bugs System
Pushed into 5.1.24-rc
[3 Mar 2008 18:18] Bugs System
Pushed into 6.0.5-alpha
[2 Apr 2008 19:49] Jon Stephens
Pushed into 5.1.23-ndb-6.3.11.
[16 Apr 2008 14:14] Paul DuBois
Noted in 5.1.24, 6.0.5 changelogs.

The per-thread debugging settings stack was not being deallocated
before thread termination, resulting in a stack memory leak.