MySQL Bugs: #35034: Falcon crash on complex I_S query in ResultSet::setValue, ResultSet.cpp line 154

Bug #35034	Falcon crash on complex I_S query in ResultSet::setValue, ResultSet.cpp line 154
Submitted:	4 Mar 2008 14:35	Modified:	29 Sep 2008 16:46
Reporter:	Philip Stoev	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0-falcon-team	OS:	Any
Assigned to:	Kevin Lewis	CPU Architecture:	Any
Tags:	simpler_testcase_needed

Description:
A complex I_S query will crash Falcon with the following stack trace:

#0  0x00110402 in __kernel_vsyscall ()
#1  0x00bdc617 in pthread_kill () from /lib/libpthread.so.0
#2  0x0842ba5c in write_core (sig=11) at stacktrace.c:240
#3  0x082912a6 in handle_segfault (sig=11) at mysqld.cc:2313
#4  <signal handler called>
#5  0x0852e4c0 in ResultSet::setValue (this=0xb72db400, column=2, value=0xb725b354) at ResultSet.cpp:154
#6  0x08516247 in NSelect::next (this=0xb7189010, statement=0xb72dc470, resultSet=0xb72db400) at NSelect.cpp:386
#7  0x0852d6e3 in ResultSet::next (this=0xb72db400) at ResultSet.cpp:134
#8  0x08496d25 in StorageHandler::getTablesInfo (this=0xb735c028, infoTable=0xa9a39db0) at StorageHandler.cpp:1017
#9  0x08488f74 in NfsPluginHandler::callTablesInfo (thd=0xa9b57a38, tables=0xa6afc00, cond=0xa762a40) at ha_falcon.cpp:2801
#10 0x083ea1fe in get_schema_tables_result (join=0xa6d2d10, executed_place=PROCESSED_BY_JOIN_EXEC) at sql_show.cc:6217
#11 0x08328afa in JOIN::exec (this=0xa6d2d10) at sql_select.cc:2246
#12 0x083258ae in mysql_select (thd=0xa9b57a38, rref_pointer_array=0xa9b58b84, tables=0xa6af9b8, wild_num=1, fields=@0xa9b58b14, conds=0x0, og_num=0,
    order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2684635648, result=0xa6d2d00, unit=0xa9b587f8, select_lex=0xa9b58a80)
    at sql_select.cc:2901
#13 0x0832a9d6 in handle_select (thd=0xa9b57a38, lex=0xa9b5879c, result=0xa6d2d00, setup_tables_done_option=0) at sql_select.cc:282
#14 0x082a0130 in execute_sqlcom_select (thd=0xa9b57a38, all_tables=0xa6af9b8) at sql_parse.cc:4517
#15 0x082a1684 in mysql_execute_command (thd=0xa9b57a38) at sql_parse.cc:1845
#16 0x082a9e5e in mysql_parse (thd=0xa9b57a38,
    inBuf=0xa6af718 "SELECT * FROM INFORMATION_SCHEMA.TABLES\nINNER JOIN INFORMATION_SCHEMA.FALCON_TABLES ON (TABLES.TABLE_SCHEMA = FALCON_TABLES.SCHEMA_NAME AND TABLES.TABLE_NAME = FALCON_TABLES.TABLE_NAME)", length=185, found_semicolon=0xa9a3b280) at sql_parse.cc:5410
#17 0x082aa871 in dispatch_command (command=COM_QUERY, thd=0xa9b57a38,
    packet=0xa9b2b619 "SELECT * FROM INFORMATION_SCHEMA.TABLES\nINNER JOIN INFORMATION_SCHEMA.FALCON_TABLES ON (TABLES.TABLE_SCHEMA = FALCON_TABLES.SCHEMA_NAME AND TABLES.TABLE_NAME = FALCON_TABLES.TABLE_NAME)", packet_length=185) at sql_parse.cc:921
#18 0x082ab9f7 in do_command (thd=0xa9b57a38) at sql_parse.cc:697
#19 0x08299d21 in handle_one_connection (arg=0xa9b57a38) at sql_connect.cc:1146
#20 0x00bd750b in start_thread () from /lib/libpthread.so.0
#21 0x00b18b2e in clone () from /lib/libc.so.6

How to repeat:
A simpler test case will hopefully follow shortly.

Chris, Should there be a shared lock on syncDDL here?

The testcase for this bug;

SELECT * FROM INFORMATION_SCHEMA.TABLES
INNER JOIN INFORMATION_SCHEMA.FALCON_TABLES 
ON (TABLES.TABLE_SCHEMA = FALCON_TABLES.SCHEMA_NAME AND
    TABLES.TABLE_NAME = FALCON_TABLES.TABLE_NAME)

requires the use of an I_S table that no longer exists (TABLE_NAME).  Sergey Vojtovich deleted that table and functions like StorageHandler::getTablesInfo() which occur in the call stack for this bug.  So this bug can no longer occur.

The work was committed 2008-07-29 in this patch;
     http://lists.mysql.com/commits/50640