[MDEV-348] 5.5 valgrind warinings on maria tests Created: 2012-06-16  Updated: 2012-06-20  Due: 2012-06-26  Resolved: 2012-06-20

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.27

Type: Bug Priority: Major
Reporter: Sergei Golubchik Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None


 Description   

valgrind reports memory leaks in a maria.maria-autozerofill an maria.maria_showlog_error tests in 5.5.

Safemalloc does not, so perhaps valgrind is just confused here?



 Comments   
Comment by Sergei Petrunia [ 2012-06-18 ]

On my machine: maria_showlog_error repeats at random. Doesn't repeat when the test is run alone.

maria.maria-autozerofill repeatably produces this:
maria.maria-autozerofill [ pass ] 10660
***Warnings generated in error logs during shutdown after running tests: maria.maria-autozerofill

==24615== 72 bytes in 1 blocks are definitely lost in loss record 1 of 2
==24615== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==24615== by 0xC1917F: my_malloc (my_malloc.c:41)
==24615== by 0xABBAF2: maria_open (ma_open.c:877)
==24615== by 0xA7BAA6: ha_maria::open(char const*, int, unsigned int) (ha_maria.cc:1157)
==24615== by 0x7B3107: handler::ha_open(TABLE*, char const*, int, unsigned int) (handler.cc:2242)
==24615== by 0x6C592C: open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool) (table.cc:2598)
==24615== by 0x5AC768: auto_repair_table(THD*, TABLE_LIST*) (sql_base.cc:3973)
==24615== by 0x5ACC61: Open_table_context::recover_from_failed_open(THD*) (sql_base.cc:4158)
==24615== by 0x5AE30E: open_tables(THD*, TABLE_LIST*, unsigned int, unsigned int, Prelocking_strategy*) (sql_base.cc:4993)
==24615== by 0x5AF111: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) (sql_base.cc:5563)
==24615== by 0x5A2834: open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) (sql_base.h:493)
==24615== by 0x60C66F: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:4579)
==24615== by 0x605B56: mysql_execute_command(THD*) (sql_parse.cc:2189)
==24615== by 0x60F051: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5736)
==24615== by 0x603203: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1055)
==24615== by 0x6024F3: do_command(THD*) (sql_parse.cc:794)

Comment by Sergei Petrunia [ 2012-06-18 ]
  • The testcase in maria.maria-autozerofill can be cut at line # 62 (the rest of the file is irrelevant) and will still produce the warning
  • I've manually traced my_malloc() / my_free() calls: there is only one my_malloc() call made with this stack trace. it DOES HAVE the corresponding my_free() call.
Comment by Sergei Petrunia [ 2012-06-18 ]

Stack trace of the my_free() call :

#0 my_free (ptr=0x7fffdc051620)
at /home/psergey/dev2/5.5/mysys/my_malloc.c:120
#1 0x0000000000a6b98a in _ma_remove_not_visible_states (
org_history=0x7fffdc051620, all=1 '\001', trnman_is_locked=1 '\001')
at /home/psergey/dev2/5.5/storage/maria/ma_state.c:187
#2 0x0000000000a6ba13 in _ma_remove_not_visible_states_with_lock (
share=0x7fffdc02b470, all=1 '\001')
at /home/psergey/dev2/5.5/storage/maria/ma_state.c:219
#3 0x0000000000affa6b in maria_close (info=0x7fffdc07c790)
at /home/psergey/dev2/5.5/storage/maria/ma_close.c:185
#4 0x0000000000a7beb2 in ha_maria::close (this=0x7fffdc015128)
at /home/psergey/dev2/5.5/storage/maria/ha_maria.cc:1223
#5 0x00000000007b3404 in handler::ha_close (this=0x7fffdc015128)
at /home/psergey/dev2/5.5/sql/handler.cc:2287
#6 0x00000000006c5d01 in closefrm (table=0x7fffdc0273e0, free_share=true)
at /home/psergey/dev2/5.5/sql/table.cc:2692
#7 0x00000000005a69b3 in intern_close_table (table=0x7fffdc0273e0)
at /home/psergey/dev2/5.5/sql/sql_base.cc:928
#8 0x00000000005a6a20 in free_cache_entry (table=0x7fffdc0273e0)
at /home/psergey/dev2/5.5/sql/sql_base.cc:951
#9 0x00000000005a6d9e in close_cached_tables (thd=0x1df7790, tables=0x0,
wait_for_refresh=true, timeout=31536000)
at /home/psergey/dev2/5.5/sql/sql_base.cc:1058
--Type <return> to continue, or q <return> to quit--
#10 0x00000000007285a2 in reload_acl_and_cache (thd=0x1df7790, options=4,
tables=0x0, write_to_binlog=0x7fffe85471fc)
at /home/psergey/dev2/5.5/sql/sql_reload.cc:272
#11 0x0000000000609c78 in mysql_execute_command (thd=0x1df7790)
at /home/psergey/dev2/5.5/sql/sql_parse.cc:3669
#12 0x000000000060f092 in mysql_parse (thd=0x1df7790,
rawbuf=0x7fffdc0c48b8 "flush tables", length=12,
parser_state=0x7fffe85475e0)

Comment by Sergei Petrunia [ 2012-06-18 ]

The problem was added by this push:

revno: 3436 [merge]
revision-id: monty@askmonty.org-20120615103907-zdf8ue47hkwo4ucc
parent: igor@askmonty.org-20120615070120-rqpwevfxxe01x3zc
parent: monty@askmonty.org-20120615103634-hvcc6weer1kraukx
committer: Michael Widenius <monty@askmonty.org>
branch nick: maria-5.5
timestamp: Fri 2012-06-15 13:39:07 +0300
message:
Automatic merge

Comment by Sergei Petrunia [ 2012-06-18 ]

More exactly, the source of the problem is here:

revno: 3434.1.1
revision-id: monty@askmonty.org-20120615095258-vabra8ei9h2zqal5
parent: igor@askmonty.org-20120613232847-h9stskwc5hd0k75c
fixes bug(s): https://launchpad.net/bugs/1007967
committer: Michael Widenius <monty@askmonty.org>
branch nick: maria-5.5
timestamp: Fri 2012-06-15 12:52:58 +0300
message:
Fixed MDEV-306 / LP:1007967 - Assertion `table->file->stats.records > 0 || error' failed join_read_const_table on concurrent SELECT and DROP/ADD INDEX

Comment by Sergei Petrunia [ 2012-06-18 ]

By Kristian:
Patch to print out memory alloc/free's : https://gist.github.com/2948260
its output: https://gist.github.com/2948256

Comment by Michael Widenius [ 2012-06-19 ]

Thanks for the input. Will start looking at this now

Comment by Michael Widenius [ 2012-06-20 ]

Fix pushed into 5.5

Generated at Thu Feb 08 06:28:05 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.