| Bug #14210 | Simple query with > operator on large table gives server crash | ||
|---|---|---|---|
| Submitted: | 21 Oct 2005 14:03 | Modified: | 9 Nov 2005 2:51 |
| Reporter: | Berto van de Kraats | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S1 (Critical) |
| Version: | 5.0.16-nightly-20051017-debug | OS: | Linux (Suse sles9 sp1) |
| Assigned to: | Konstantin Osipov | CPU Architecture: | Any |
[21 Oct 2005 14:06]
Berto van de Kraats
Cpp trace of problam
Attachment: bug14210.cpp (text/plain), 26.96 KiB.
[21 Oct 2005 14:06]
Berto van de Kraats
Table data for repro
Attachment: bug14210.bz2.gz (application/x-gzip, text), 202.48 KiB.
[21 Oct 2005 14:38]
Valeriy Kravchuk
Thank you for a problem report. I was not able to repeat the behaviour you described using your data on 5.0.15-BK (ChangeSet@1.2022, 2005-10-20 11:12:34+05:00, bar@mysql.com) built from sources: The following SELECT: mysql> SELECT * FROM tcisli245090 a0 WHERE (a0.t_slcp >= 90); ... 17107 rows in set (17,74 sec) just worked for me. And here is the plan: mysql> explain SELECT * FROM tcisli245090 a0 WHERE (a0.t_slcp >= 90); +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ | 1 | SIMPLE | a0 | range | PRIMARY | PRIMARY | 4 | NULL | 8564 | Using where | +----+-------------+-------+-------+---------------+---------+---------+------+- -----+-------------+ 1 row in set (0,10 sec) mysql> exit Bye [openxs@Fedora 5.0]$ uname -a Linux Fedora 2.4.22-1.2115.nptl #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux So, what value was used instead of ? when you get that crash? Can you add something that will help me to repeat it?
[21 Oct 2005 14:41]
Berto van de Kraats
I've noticed the same. When the query is run from mysql, then there is no problem. But, if the attached program is used, then I get a crash (note that the program uses the "client cursor" functionality).
[21 Oct 2005 18:34]
MySQL Verification Team
Thank you for the bug report and test case.
051021 16:27:40 [Note] /home/miguel/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.16-debug' socket: '/tmp/mysql.sock' port: 3306 Source distribution
[New Thread 1132456880 (LWP 7380)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1132456880 (LWP 7380)]
0x00000000 in ?? ()
(gdb) bt full
#0 0x00000000 in ?? ()
No symbol table info available.
#1 0x0833092c in Materialized_cursor::fetch (this=0x8e87730, num_rows=1) at sql_cursor.cc:589
thd = (class THD *) 0x8e3d3f8
res = 0
#2 0x082550aa in mysql_stmt_fetch (thd=0x8e3d3f8, packet=0x8e619c9 "\001", packet_length=9) at sql_prepare.cc:2329
stmt_id = 1
num_rows = 1
stmt = (Prepared_statement *) 0x8e659f0
stmt_backup = {<ilink> = {_vptr.ilink = 0x85dd1a8, prev = 0x0, next = 0x0}, <Query_arena> = {_vptr.Query_arena = 0x85dd1bc,
free_list = 0x85b1f48, mem_root = 0x43000000, is_backup_arena = false, state = 1132452252}, main_mem_root = {free = 0x0, used = 0x0,
pre_alloc = 0x0, min_malloc = 0, block_size = 8684676, block_num = 0, first_block_usage = 0, error_handler = 0x8e659f0}, main_lex = {
_vptr.st_lex = 0x85b1f98, yylineno = 0, yytoklen = 0, yylval = 0x0, unit = {<st_select_lex_node> = {
_vptr.st_select_lex_node = 0x85b1ee8, next = 0x8e69a28, prev = 0x3, master = 0x437fdfdc, slave = 0x86a4750, link_next = 0x8e69a55,
link_prev = 0x9, options = 641370937777709020, uncacheable = 0 '\0', linkage = UNSPECIFIED_TYPE, no_table_names_allowed = 117,
<cut>
[2 Nov 2005 14:40]
Konstantin Osipov
Similarly to Bug#14143, this bug report is not easily repeatable: kostja@dragonfly:~> ./a.out !!! Error (708): Expected value:1 Returned value:0 mysql error: a.out: ./bug14210.cpp:708: int main(): Assertion `0' failed. zsh: 1464 abort (core dumped) ./a.out Analyzing valgrind ouptut.
[3 Nov 2005 11:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/31877
[3 Nov 2005 13:57]
Konstantin Osipov
Fixed in 5.0 tree, currently tagged 5.0.16
[3 Nov 2005 14:00]
Konstantin Osipov
Note for documentation: the bug was in memory corruption caused by any cursor query that returns a result set bigger than max_heap_table_size.
[9 Nov 2005 2:51]
Paul DuBois
Noted in 5.0.16 changelog.
Description: A simple query such as the following causes the mysqld to crash. If I make the table a bit smaller (delete some 500 rows) then the problem goes away. SELECT * FROM tcisli245090 a0 WHERE (a0.t_slcp >= ?) The backtrace is as follows: #0 0x00000000 in ?? () #1 0x082bc280 in Materialized_cursor::fetch (this=0x8bdc930, num_rows=1) at sql_cursor.cc:589 #2 0x082038e0 in mysql_stmt_fetch (thd=0x8b8e6a0, packet=0x8bbb0c1 "\001", packet_length=9) at sql_prepare.cc:2329 #3 0x0819e1c3 in dispatch_command (command=COM_STMT_FETCH, thd=0x8b8e6a0, packet=0x8bbb0c1 "\001", packet_length=9) at sql_parse.cc:1663 #4 0x0819dbf6 in do_command (thd=0x8b8e6a0) at sql_parse.cc:1498 #5 0x0819cda0 in handle_one_connection (arg=0x8b8e6a0) at sql_parse.cc:1143 #6 0x4004ca13 in start_thread () from /lib/tls/libpthread.so.0 #7 0x4023c9da in clone () from /lib/tls/libc.so.6 (gdb) f 1 #1 0x082bc280 in Materialized_cursor::fetch (this=0x8bdc930, num_rows=1) at sql_cursor.cc:589 589 if ((res= table->file->rnd_next(table->record[0]))) (gdb) p *table->file $1 = {<Sql_alloc> = {<No data fields>}, _vptr.handler = 0x8f8f8f8f, table = 0x8f8f8f8f, ht = 0x8f8f8f8f, ref = 0x8f8f8f8f "", dupp_ref = 0x8f8f8f8f "", data_file_length = 10344644715844964239, max_data_file_length = 10344644715844964239, index_file_length = 10344644715844964239, max_index_file_length = 10344644715844964239, delete_length = 10344644715844964239, auto_increment_value = 10344644715844964239, records = 2408550287, deleted = 2408550287, raid_chunksize = 2408550287, mean_rec_length = 2408550287, create_time = -1886417009, check_time = -1886417009, update_time = -1886417009, multi_range_sorted = 143, multi_range_curr = 0x8f8f8f8f, multi_range_end = 0x8f8f8f8f, multi_range_buffer = 0x8f8f8f8f, save_end_range = {key = 0x8f8f8f8f "", length = 2408550287, flag = 2408550287}, end_range = 0x8f8f8f8f, range_key_part = 0x8f8f8f8f, key_compare_result_on_equal = -1886417009, eq_range = 143, errkey = 2408550287, sortkey = 2408550287, key_used_on_scan = 2408550287, active_index = 2408550287, ref_length = 2408550287, block_size = 2408550287, raid_type = 2408550287, raid_chunks = 2408550287, ft_handler = 0x8f8f8f8f, inited = 2408550287, auto_increment_column_changed = 143, implicit_emptied = 143, pushed_cond = 0x8f8f8f8f} How to repeat: Use the attached program and table dump. If the problem reproduces then the program runs silently and the mysqld crashes.