MySQL Bugs: #52727: valgrind leak warning after main.innodb-autoinc

Bug #52727	valgrind leak warning after main.innodb-autoinc
Submitted:	9 Apr 2010 17:32	Modified:	26 May 2010 10:56
Reporter:	Mark Callaghan	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB Plugin storage engine	Severity:	S3 (Non-critical)
Version:	5.1.45	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	autoinc, innodb, plugin, valgrind

Description:
When I use MySQL 5.1.45 and the 1.0.6 InnoDB plugin and potentially modified tests to not fail with the plugin, valgrind warns of a memory leak from dict_mem_table_create

This is the error. It only is reported when tests are run in sequence. If main.innodb-autoinc is run alone, then I don't get the report.

==23442==
==23442== 1,960 bytes in 3 blocks are still reachable in loss record 2 of 2
==23442== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==23442== by 0x7803BB: mem_heap_create_block (mem0mem.c:333)
==23442== by 0x7804C5: mem_heap_add_block (mem0mem.c:432)
==23442== by 0x81DFDE: dict_mem_table_create (mem0mem.ic:186)
==23442== by 0x7A68D4: row_merge_create_temporary_table (row0merge.c:2169)
==23442== by 0x766820: ha_innobase::add_index(st_table*, st_key*, unsigned) (handler0alter.cc:725)
==23442== by 0x6BE349: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned, st_order*, bool) (sql_table.cc:7233)
==23442== by 0x5B073B: mysql_execute_command(THD*, unsigned long long*) (sql_parse.cc:3076)
==23442== by 0x5B3A60: mysql_parse(THD*, char const*, unsigned, char const**, unsigned long long*) (sql_parse.cc:6256)
==23442== by 0x5B4F37: dispatch_command(enum_server_command, THD*, char*, unsigned) (sql_parse.cc:1259)
==23442== by 0x5B5B3D: do_command(THD*) (sql_parse.cc:895)
==23442== by 0x5A45BD: handle_one_connection (sql_connect.cc:1131)
==23442== by 0x328F8062F6: start_thread (in /lib64/libpthread-2.5.so)
==23442== by 0x328ECD1E3C: clone (in /lib64/libc-2.5.so)
==23442==

How to repeat:
MySQL 5.1.45
InnoDB 1.0.6 plugin
server configured to build InnoDB plugin but not InnoDB builtin
plugin statically linked so I don't have to enable it with mtr options
gcc 4.1.2
valgrind 3.2.1
centos 5.2

all tests pass, we may have modified them to achieve that but I don't remember for sure

./configure --enable-thread-safe-client
--with-plugins=csv,blackhole,myisam,heap,innodb_plugin
--without-plugin-innobase --with-fast-mutexes --with-extra-charsets=all
--with-debug C_EXTRA_FLAGS="-fno-omit-frame-pointer -DHAVE_purify
-DNO_ALARM -DSIGNAL_WITH_VIO_CLOSE"

Run these tests in sequence:
innodb.innodb-analyze
innodb.innodb-index
innodb.innodb-index_ucs2
innodb.innodb-timeout
innodb.innodb-zip
innodb.innodb_bug36169
innodb.innodb_bug36172
innodb.innodb_bug40360
innodb.innodb_bug41904
innodb.innodb_bug44032
innodb.innodb_bug44571
innodb.innodb_bug46676
innodb.innodb_bug47167
innodb.innodb_file_format
innodb.innodb_information_schema
main.consistent_snapshot
main.deadlock_innodb
main.endspace
main.events_trans
main.events_trans_notembedded
main.flush_block_commit
main.func_group_innodb
main.func_rollback
main.group_min_max_innodb
main.handler_innodb
main.handler_open_read_close_innodb
main.index_merge_innodb
main.information_schema_inno
main.innodb-autoinc

Thank you for the report.

I can not repeat described behavior with 1.0.7 plugin, although bug is repeatable with 1.0.6. So closed as "Can't repeat"

When do we get the 1.0.7 plugin?

I was pushed into 5.1 tree and will be available since version 5.1.46. For now please use either bzr tree or snapshot.

Why was this closed with 'cannot repeat' rather than fixed? The bug is in the most recent GA release and you were able to reproduce it. I don't want someone to look at my bug summaries and assume I am wasting your time.

Thank you for the feedback.

Because it was fixed by one of numerous change in InnoDB Plugin code and I can not provide link to exact patch which fixed the bug.

This is repeatable with InnoDB Plugin 1.0.6 but not with 1.0.7. I did not see anything obvious in the change history that would explain this. I plan to track down the exact revision where the bug goes away. It could be something that merely hides the bug or reduces the probability of occurrence.

I was unable to repeat this error so far, but I must have used a slightly different bzr tree. I did see another warning in 1.0.6, about block->is_hashed being uninitialized in buf_pool_drop_hash_index(). That one did not occur in 1.0.7.

Can you repeat this with MySQL 5.1.46?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".