Bug #40480 valgrind errors which are not seen in PB

Submitted: 3 Nov 2008 16:32 Modified: 26 Nov 2008 16:04
Reporter: Rafal Somla Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Backup Severity:S3 (Non-critical)
Version:6.0 OS:Any
Assigned to: Øystein Grøvlen CPU Architecture:Any

[3 Nov 2008 16:32] Rafal Somla 
Description:
I can see the following valgrind stacks when running backup test suite with --valgrind option.

==8671== Conditional jump or move depends on uninitialised value(s)
==8671==    at 0x89BCFBE: backup::Logger::last_saved_error() (logger.h:186)
==8671==    by 0x89BACAB: send_error(Backup_restore_ctx&, int, ...) (kernel.cc:259)
==8671==    by 0x89BC830: execute_backup_command(THD*, LEX*, String*) (kernel.cc:149)
==8671==    by 0x830AAF6: mysql_execute_command(THD*) (sql_parse.cc:2236)
==8671==    by 0x83128EC: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5634)
==8671==    by 0x83138E0: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==8671==    by 0x8314BF9: do_command(THD*) (sql_parse.cc:689)
==8671==    by 0x8301F24: handle_one_connection (sql_connect.cc:1156)
==8671==    by 0x404E0BC: start_thread (in /lib/tls/libpthread-2.3.6.so)
==8671==    by 0x42949ED: clone (in /lib/tls/libc-2.3.6.so)
==8671== 
==8671== Conditional jump or move depends on uninitialised value(s)
==8671==    at 0x89C07F1: util::report_mysql_error(THD*, util::SAVED_MYSQL_ERROR*, int) (error.h:26)
==8671==    by 0x89BACD7: send_error(Backup_restore_ctx&, int, ...) (kernel.cc:261)
==8671==    by 0x89BC830: execute_backup_command(THD*, LEX*, String*) (kernel.cc:149)
==8671==    by 0x830AAF6: mysql_execute_command(THD*) (sql_parse.cc:2236)
==8671==    by 0x83128EC: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5634)
==8671==    by 0x83138E0: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==8671==    by 0x8314BF9: do_command(THD*) (sql_parse.cc:689)
==8671==    by 0x8301F24: handle_one_connection (sql_connect.cc:1156)
==8671==    by 0x404E0BC: start_thread (in /lib/tls/libpthread-2.3.6.so)
==8671==    by 0x42949ED: clone (in /lib/tls/libc-2.3.6.so)
==8671== 

Note that these problems are not reported by PB.

How to repeat:
Compile the main 6.0 tree using BUILD/compile-*-valgrind-max. Then run

./mtr --valgrind --suite=backup

and look into var/log/master.err

Suggested fix:
Initialize uninitialized variables.
[3 Nov 2008 19:09] Sveta Smirnova 
Thank you for the report.

Verified as described.
[10 Nov 2008 10:07] Øystein Grøvlen 
I get the following in master.err when running backup_errors test:

==22967== Thread 15:
==22967== Conditional jump or move depends on uninitialised value(s)
==22967==    at 0x875A9E5: send_error(Backup_restore_ctx&, int, ...) (logger.h:188)
==22967==    by 0x875B061: execute_backup_command(THD*, LEX*, String*) (kernel.cc:149)
==22967==    by 0x829AB94: mysql_execute_command(THD*) (sql_parse.cc:2324)
==22967==    by 0x82A1C10: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==22967==    by 0x82A2BD8: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==22967==    by 0x82A3E65: do_command(THD*) (sql_parse.cc:689)
==22967==    by 0x8292F19: handle_one_connection (sql_connect.cc:1156)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==22967== 
==22967== Conditional jump or move depends on uninitialised value(s)
==22967==    at 0x875A9F5: send_error(Backup_restore_ctx&, int, ...) (error.h:26)
==22967==    by 0x875B061: execute_backup_command(THD*, LEX*, String*) (kernel.cc:149)
==22967==    by 0x829AB94: mysql_execute_command(THD*) (sql_parse.cc:2324)
==22967==    by 0x82A1C10: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==22967==    by 0x82A2BD8: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==22967==    by 0x82A3E65: do_command(THD*) (sql_parse.cc:689)
==22967==    by 0x8292F19: handle_one_connection (sql_connect.cc:1156)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==22967== 
==22967== Conditional jump or move depends on uninitialised value(s)
==22967==    at 0x875AA00: send_error(Backup_restore_ctx&, int, ...) (error.h:30)
==22967==    by 0x875B061: execute_backup_command(THD*, LEX*, String*) (kernel.cc:149)
==22967==    by 0x829AB94: mysql_execute_command(THD*) (sql_parse.cc:2324)
==22967==    by 0x82A1C10: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==22967==    by 0x82A2BD8: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==22967==    by 0x82A3E65: do_command(THD*) (sql_parse.cc:689)
==22967==    by 0x8292F19: handle_one_connection (sql_connect.cc:1156)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)

...
==22967== 
==22967== ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 29 from 1)
==22967== malloc/free: in use at exit: 9,500 bytes in 24 blocks.
==22967== malloc/free: 29,059 allocs, 29,035 frees, 71,048,466 bytes allocated.
==22967== For counts of detected errors, rerun with: -v
==22967== searching for pointers to 24 not-freed blocks.
==22967== checked 60,631,716 bytes.
==22967== 
==22967== Thread 1:
==22967== 
==22967== 8 bytes in 1 blocks are indirectly lost in loss record 1 of 4
==22967==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==22967==    by 0x86C0575: my_malloc (my_malloc.c:34)
==22967==    by 0x8284F25: String::real_alloc(unsigned) (sql_string.cc:52)
==22967==    by 0x82850A9: String::copy(String const&) (sql_string.h:198)
==22967==    by 0x84532EC: Backup_log::add_driver(char const*) (si_logs.cc:66)
==22967==    by 0x876C765: Backup_info::close() (logger.h:298)
==22967==    by 0x875B261: execute_backup_command(THD*, LEX*, String*) (kernel.cc:191)
==22967==    by 0x829AB94: mysql_execute_command(THD*) (sql_parse.cc:2324)
==22967==    by 0x82A1C10: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==22967==    by 0x82A2BD8: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==22967==    by 0x82A3E65: do_command(THD*) (sql_parse.cc:689)
==22967==    by 0x8292F19: handle_one_connection (sql_connect.cc:1156)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==22967== 
==22967== 
==22967== 28 bytes in 1 blocks are still reachable in loss record 2 of 4
==22967==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==22967==    by 0x400BF4F: (within /lib/ld-2.7.so)
==22967==    by 0x4011593: (within /lib/ld-2.7.so)
==22967==    by 0x400D5C5: (within /lib/ld-2.7.so)
==22967==    by 0x4010F4D: (within /lib/ld-2.7.so)
==22967==    by 0x42D7291: (within /lib/tls/i686/cmov/libc-2.7.so)
==22967==    by 0x400D5C5: (within /lib/ld-2.7.so)
==22967==    by 0x42D7454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==22967==    by 0x4043686: pthread_cancel_init (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x40437B0: _Unwind_ForcedUnwind (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x4041210: __pthread_unwind (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x403B5EF: pthread_exit (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x86D9681: nptl_pthread_exit_hack_handler (my_thr_init.c:66)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==22967== 
==22967== 
==22967== 8,608 (8,600 direct, 8 indirect) bytes in 16 blocks are definitely lost in loss record 4 of 4
==22967==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==22967==    by 0x86C116E: operator new(unsigned) (my_new.cc:27)
==22967==    by 0x875A37C: Backup_restore_ctx::prepare_for_backup(String*, st_mysql_lex_string, char const*, bool) (logger.h:334)
==22967==    by 0x875B17A: execute_backup_command(THD*, LEX*, String*) (kernel.cc:170)
==22967==    by 0x829AB94: mysql_execute_command(THD*) (sql_parse.cc:2324)
==22967==    by 0x82A1C10: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==22967==    by 0x82A2BD8: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==22967==    by 0x82A3E65: do_command(THD*) (sql_parse.cc:689)
==22967==    by 0x8292F19: handle_one_connection (sql_connect.cc:1156)
==22967==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==22967==    by 0x429FE5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==22967== 
==22967== LEAK SUMMARY:
==22967==    definitely lost: 8,600 bytes in 16 blocks.
==22967==    indirectly lost: 8 bytes in 1 blocks.
==22967==      possibly lost: 0 bytes in 0 blocks.
==22967==    still reachable: 28 bytes in 1 blocks.
==22967==         suppressed: 864 bytes in 6 blocks.
[11 Nov 2008 7:59] Øystein Grøvlen 
The backup_tablespace test gives the following backup related valgrind errors:

==12017== 104 bytes in 1 blocks are definitely lost in loss record 2 of 4
==12017==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==12017==    by 0x882FA67: operator new(unsigned) (my_new.cc:27)
==12017==    by 0x84F99D2: obs::get_tablespace_from_schema(THD*, obs::TablespaceObj**, String const*, String const*) (si_objects.cc:3643)
==12017==    by 0x84F9ACA: obs::is_tablespace(THD*, obs::Obj*) (si_objects.cc:3760)
==12017==    by 0x88F372B: bcat_create_item (kernel.cc:1968)
==12017==    by 0x890506D: read_and_create_items (stream_v1.c:1641)
==12017==    by 0x8904A14: bstream_rd_meta_data (stream_v1.c:1305)
==12017==    by 0x88FA5F7: backup::read_meta_data(backup::Image_info&, backup::Input_stream&) (stream.h:199)
==12017==    by 0x88F52C0: Backup_restore_ctx::do_restore() (kernel.cc:1228)
==12017==    by 0x88F6D2B: execute_backup_command(THD*, LEX*, String*) (kernel.cc:229)
==12017==    by 0x82FBE3C: mysql_execute_command(THD*) (sql_parse.cc:2324)
==12017==    by 0x83042C0: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==12017==    by 0x8304E45: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1009)
==12017==    by 0x830641E: do_command(THD*) (sql_parse.cc:689)
==12017==    by 0x82F397C: handle_one_connection (sql_connect.cc:1156)
==12017==    by 0x403A4FA: start_thread (in /lib/tls/i686/cmov/libpthread-2.7.so)
==12017== 
==12017== 
==12017== 152 bytes in 4 blocks are still reachable in loss record 3 of 4
==12017==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==12017==    by 0x882E8A6: _mymalloc (safemalloc.c:137)
==12017==    by 0x82E2E14: String::real_alloc(unsigned) (sql_string.cc:52)
==12017==    by 0x8257F81: String::alloc(unsigned) (sql_string.h:198)
==12017==    by 0x82E3432: String::copy(String const&) (sql_string.cc:141)
==12017==    by 0x84F4929: obs::TablespaceObj::TablespaceObj(String const*) (si_objects.cc:2902)
==12017==    by 0x84F99E3: obs::get_tablespace_from_schema(THD*, obs::TablespaceObj**, String const*, String const*) (si_objects.cc:3643)
==12017==    by 0x84F9ACA: obs::is_tablespace(THD*, obs::Obj*) (si_objects.cc:3760)
==12017==    by 0x88F372B: bcat_create_item (kernel.cc:1968)
==12017==    by 0x890506D: read_and_create_items (stream_v1.c:1641)
==12017==    by 0x8904A14: bstream_rd_meta_data (stream_v1.c:1305)
==12017==    by 0x88FA5F7: backup::read_meta_data(backup::Image_info&, backup::Input_stream&) (stream.h:199)
==12017==    by 0x88F52C0: Backup_restore_ctx::do_restore() (kernel.cc:1228)
==12017==    by 0x88F6D2B: execute_backup_command(THD*, LEX*, String*) (kernel.cc:229)
==12017==    by 0x82FBE3C: mysql_execute_command(THD*) (sql_parse.cc:2324)
==12017==    by 0x83042C0: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5722)
==12017==
[11 Nov 2008 8:57] 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/58420

2731 oystein.grovlen@sun.com	2008-11-11
      Bug#40480 - valgrind errors which are not seen in PB
      
      Fixes all backup related issues reported by valgrind when running 
      the backup test suite.
[13 Nov 2008 13:03] 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/58632

2732 oystein.grovlen@sun.com	2008-11-13
      Bug#40480 - valgrind errors which are not seen in PB
      
      Fixes all backup related issues reported by valgrind when running 
      the backup test suite.
      
      Also fixes a by accident shallow copy of Logger to make sure Logger destructs
      Backup_log object only once.  Added private copy constructors to prevent 
      similar accidents in the future.
[13 Nov 2008 15:05] Rafal Somla 
Good to push.
[14 Nov 2008 7:28] Øystein Grøvlen 
pushed to mysql-6.0-backup (revid; oystein.grovlen@sun.com-20081113130236-shpcfdh1kn7ot14u)
[26 Nov 2008 8:50] Bugs System 
Pushed into 6.0.9-alpha  (revid:oystein.grovlen@sun.com-20081113130236-shpcfdh1kn7ot14u) (version source revid:jorgen.loland@sun.com-20081126084449-lq9ckif3hmxesy1n) (pib:5)
[26 Nov 2008 16:04] Paul DuBois 
Noted in 6.0.9 changelog.

Several MySQL Backup-related memory-use issues identified by Valgrind
were corrected.
[10 Dec 2008 5:42] 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/61141

2742 He Zhenxing	2008-12-10 [merge]
      Auto Merge

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.077 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.