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:
None 
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:03] Berto van de Kraats
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.
[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] Miguel Solorzano
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.