Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5.27
    • Component/s: None
    • 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?

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            psergey Sergei Petrunia added a comment -

            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)

            Show
            psergey Sergei Petrunia added a comment - 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)
            Hide
            psergey Sergei Petrunia added a comment -
            • 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.
            Show
            psergey Sergei Petrunia added a comment - 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.
            Hide
            psergey Sergei Petrunia added a comment -

            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)

            Show
            psergey Sergei Petrunia added a comment - 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)
            Hide
            psergey Sergei Petrunia added a comment -

            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

            Show
            psergey Sergei Petrunia added a comment - 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
            Hide
            psergey Sergei Petrunia added a comment -

            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

            Show
            psergey Sergei Petrunia added a comment - 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
            Hide
            psergey Sergei Petrunia added a comment -

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

            Show
            psergey Sergei Petrunia added a comment - By Kristian: Patch to print out memory alloc/free's : https://gist.github.com/2948260 its output: https://gist.github.com/2948256
            Hide
            monty Michael Widenius added a comment -

            Thanks for the input. Will start looking at this now

            Show
            monty Michael Widenius added a comment - Thanks for the input. Will start looking at this now
            Hide
            monty Michael Widenius added a comment -

            Fix pushed into 5.5

            Show
            monty Michael Widenius added a comment - Fix pushed into 5.5

              People

              • Assignee:
                monty Michael Widenius
                Reporter:
                serg Sergei Golubchik
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour, 30 minutes
                  1h 30m