Bug #21609 | Mysql crashing using memory tables | ||
---|---|---|---|
Submitted: | 13 Aug 2006 6:56 | Modified: | 16 Aug 2006 16:18 |
Reporter: | Jeff C | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 5.0.24 | OS: | Linux (RHEL4) |
Assigned to: | Assigned Account | CPU Architecture: | Any |
[13 Aug 2006 6:56]
Jeff C
[14 Aug 2006 7:23]
Jeff C
After further investigation... I'm doing: lock tables sample write, sample2 write; create temporary table mymemory engine=memory select * from sample, sample2 where a.id = b.id; .. do more processing unlock tables; drop temporary table if exists mymemory; I repeatedly get signal 11's with this setup. Changing it to: create table mytable (...) ; lock tables... do processing unlock tables; drop table if exists mytable; Absolutely no signal 11's.. I'm not sure exactly where it happens but the cause is above.
[14 Aug 2006 8:24]
Sveta Smirnova
Thank you for the report. I can not repeat it on 32-bit Linux. Could you please provide output of SHOW CREATE TABLE sample, SHOW CREATE TABLE sample2 statements, correct query you using to create table mymemory and indicate you hardware?
[15 Aug 2006 5:00]
Steve Shell
I am having similiar problem with 5.0.24 on Windows XP SP2 Intel P4 3.2ghz. I downloaded the source and recompiled with Visual Studio and have the follow captured debug. My application is very active with SQL statements and several temporary tables. The application then is forcefully closed via exit(). 1. ErrorLog reported this: Version: '5.0.24-debug-log' socket: '' port: 3306 Source distribution Assertion failed: (table2->lock_position < mylock->table_count) && (table2 == lock_tables[table2->lock_position]), file C:\Programs\mysql-5.0.24\sql\lock.cpp, line 578 In the debugger there is indication that freed memory is being accessed: (0xDDDDDDD value at the line were the code had exception) Debug Context Trace: KERNEL32! 7c80b830() _threadstart(void *) pthread_start(void *) (my_winthread.c Line 63) handle_one_connection(void *) (sql_parse.cpp Line 1199) end_thread(THD *,int) mysqld.cpp (Line 1643) THD::cleanup() sql_class.cpp (Line 385) close_temporary_tables(THD *thd) sql_base.cpp (Line 629) -->thd = 0x12fa5898 -->thd->temporary_tables = 0x12fe4870 --> *temporary_tables s/file/next/prev/in_use/field --all 0xdddddd -->for (table= thd->temporary_tables; table; table= table->next) --> thd->temporary_tables = 0xdddddddd close_temporary(TABLE *table,bool delete_table) sql_base.cpp (Line 601) --> db_type table_type=table->s->db_type; *** Access to freed memory crashes --> input TABLE *table = 0xdddddddd --> input delete_table = 1 My application is all Java with a number of open connections in threads. A number of other Java apps are running, also using the database at around 100 SQL commands per second.
[15 Aug 2006 15:49]
Jeff C
I have about 10-20 different perl scripts connecting to the database, and when the loaders use this code below, mysqld crashes repeatedly. The solution is to do what I posted above... (I've modified my table names/column names but this is the exact SQL that I use to crash mysql). $limit = 500; my $sql = <<"EOF"; use loader; delete from checkout.ids where ts < now() - interval 20 minute; create tempoary table loader.todo_ids (domain varchar(71) not null primary key) engine=memory; insert ignore into loader.todo_ids (domain) select lower(s.domain) from other.db s left join checkout.ids co using(domain) where mycount is null and co.domain is null $limit; ... 4 other queries like the above just from different tables... lock table loader.todo_ids read, checkout.ids write; create temporary table toquery engine=memory select todo_ids.domain from loader.todo_ids left join checkout.ids using(domain) where ids.domain is null limit $limit; insert ignore into checkout.ids (domain) select domain from loader.toquery; unlock tables; select * from loader.toquery; drop temporary table if exists loader.todo_ids; drop temporary table if exists loader.toquery; EOF
[16 Aug 2006 16:18]
MySQL Verification Team
duplicate of bug #21582
[18 Aug 2006 21:00]
Andrei Elkin
This must be a dup of earlier bug#20919.