| Bug #58072 | LOAD DATA INFILE: leaks io cache memory when error occurs | ||
|---|---|---|---|
| Submitted: | 9 Nov 2010 8:18 | Modified: | 26 Apr 2011 15:37 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S2 (Serious) |
| Version: | 5.1.53, 5.1.54, 5.5.8 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Leak, LOAD DATA INFILE, memory leak, regression | ||
[9 Nov 2010 9:46]
Valeriy Kravchuk
Verified as described in the last comment on 32-bit Ubuntu 10.04: ... ==26248== 16,384 bytes in 1 blocks are definitely lost in loss record 8 of 8 ==26248== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==26248== by 0x85E0D24: my_malloc (my_malloc.c:35) ==26248== by 0x85DC2FE: init_io_cache (mf_iocache.c:244) ==26248== by 0x83FA278: READ_INFO::READ_INFO(int, unsigned int, charset_info_st*, String&, String&, String&, String&, int, bool, bool) (sql_load.cc:1113) ==26248== by 0x83F7C1E: mysql_load(THD*, sql_exchange*, TABLE_LIST*, List<Item>&, List<Item>&, List<Item>&, enum_duplicates, bool, bool) (sql_load.cc:382) ==26248== by 0x8291242: mysql_execute_command(THD*) (sql_parse.cc:3524) ==26248== by 0x8298EE1: mysql_parse(THD*, char*, unsigned int, char const**) (sql_parse.cc:6051) ==26248== by 0x828AD28: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1260) ==26248== by 0x8289E30: do_command(THD*) (sql_parse.cc:888) ==26248== by 0x8287FD1: handle_one_connection (sql_connect.cc:1136) ==26248== by 0x404196D: start_thread (pthread_create.c:300) ==26248== by 0x4196A4D: clone (clone.S:130) ==26248== ==26248== LEAK SUMMARY: ==26248== definitely lost: 16,384 bytes in 1 blocks ==26248== indirectly lost: 0 bytes in 0 blocks ==26248== possibly lost: 1,224 bytes in 9 blocks ==26248== still reachable: 0 bytes in 0 blocks ==26248== suppressed: 0 bytes in 0 blocks ==26248== ==26248== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 27 from 10) --26248-- --26248-- used_suppression: 27 dl-hack3-cond-1 ==26248== ==26248== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 27 from 10)
[26 Apr 2011 15:37]
Paul DuBois
Noted in 5.1.58, 5.5.13, 5.6.3 changelogs. LOAD DATA INFILE errors could leak I/O cache memory. CHANGESET - http://lists.mysql.com/commits/136076
Description: load data infile leaks memory in the iocache when load is aborted due to errors. 5.1.53: 81,920 bytes in 5 blocks are definitely lost in loss record 9 of 9 at: malloc (vg_replace_malloc.c:195) by: my_malloc (my_malloc.c:35) by: init_io_cache (mf_iocache.c:244) by: READ_INFO::READ_INFO (sql_load.cc:1113) by: mysql_load (sql_load.cc:382) by: mysql_execute_command (sql_parse.cc:3534) by: mysql_parse (sql_parse.cc:6068) by: dispatch_command (sql_parse.cc:1261) by: do_command (sql_parse.cc:889) by: handle_one_connection (sql_connect.cc:1136) by: start_thread (pthread_create.c:301) LEAK SUMMARY: definitely lost: 81,920 bytes in 5 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 2,720 bytes in 10 blocks 5.0.92 didn't leak here. How to repeat: shell> echo 1 > /tmp/file.txt run mysqld in valgrind: valgrind --leak-check=full --tool=memcheck -v /path/to/mysqld .... drop table if exists t; create table t(a point)engine=myisam; load data infile '/tmp/file.txt' into table `t`; shutdown mysqld, check valgrind... Suggested fix: i'd suggest this trivial bug be fixed asap so that random testing can find more serious bugs. additionally, every single memory leak bug must be fixed. we don't know what folks are running against their servers without checking errors. this case is a legitimation use case that results in an expected error, but unexpected memory leak.