Bug #6729 Lost connection during "regexp" query
Submitted: 20 Nov 2004 11:53 Modified: 7 Feb 2005 15:13
Reporter: Vaclav Vobornik Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S2 (Serious)
Version:bk 4.1.8-latest/5.0 OS:Linux (Linux)
Assigned to: Sergei Glukhov CPU Architecture:Any

[20 Nov 2004 11:53] Vaclav Vobornik
Description:
mysql> select cur_id, replace(cur_title,'_',' ')
    ->   from cur
    ->   where cur_namespace=0 
    ->     and (length(cur_title)>4
    ->       or cur_title regexp '\d\d\d\d')
    ->   order by length(cur_title) desc, cur_title LIMIT 0,50;
ERROR 2013 (HY000): Lost connection to MySQL server during query

In host.err:
Version: '4.1.8'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=2
max_connections=100
threads_connected=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x83e3380
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbf3fe8b8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x810c301
0x40038dfd
0x8205e49
0x82047a2
0x8204501
0x820441b
0x80cda57
0x80cce8a
0x80cce8a
0x8138fa1
0x813dc17
0x81407b1
0x81507cf
0x811d209
0x81215e1
0x811c01b
0x8123bf3
0x811b17d
0x40031463
0x4020ad64
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x83e87a8 = select cur_id, replace(cur_title,'_',' ')
  from cur
  where cur_namespace=0 
    and (length(cur_title)>4
      or cur_title regexp '\d\d\d\d')
  order by length(cur_title) desc, cur_title LIMIT 0, 50
thd->thread_id=5
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 1
041120 12:19:48  mysqld restarted
/opt/mysql/libexec/mysqld: ready for connections.

---------------------------
resolve_stack_dump produce this output:

0x810c301 handle_segfault + 425
0x40038dfd _end + 936064073
0x8205e49 ordinary + 61
0x82047a2 p_ere_exp + 446
0x8204501 p_ere + 33
0x820441b regcomp + 459
0x80cda57 fix_fields__15Item_func_regexP3THDP13st_table_listPP4Item + 595
0x80cce8a fix_fields__9Item_condP3THDP13st_table_listPP4Item + 350
0x80cce8a fix_fields__9Item_condP3THDP13st_table_listPP4Item + 350
0x8138fa1 setup_conds__FP3THDP13st_table_listPP4Item + 109
0x813dc17 prepare__4JOINPPP4ItemP13st_table_listUiP4ItemUiP8st_orderT6T4T6P13st_select_lexP18st_select_lex_unit + 375
0x81407b1 mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s + 729
0x81507cf handle_select__FP3THDP6st_lexP13select_result + 143
0x811d209 mysql_execute_command__FP3THD + 1253
0x81215e1 mysql_parse__FP3THDPcUi + 385
0x811c01b dispatch_command__F19enum_server_commandP3THDPcUi + 1691
0x8123bf3 do_command__FP3THD + 191
0x811b17d handle_one_connection + 733
0x40031463 _end + 936032943
0x4020ad64 _end + 937972656

How to repeat:
create this table:

CREATE TABLE `cur` (
  `cur_id` int(8) unsigned NOT NULL auto_increment,
  `cur_namespace` tinyint(2) unsigned NOT NULL default '0',
  `cur_title` varchar(255) collate utf8_unicode_ci NOT NULL default '',
  `cur_text` mediumtext collate utf8_unicode_ci NOT NULL,
  `cur_comment` tinytext collate utf8_unicode_ci NOT NULL,
  `cur_user` int(5) unsigned NOT NULL default '0',
  `cur_user_text` varchar(255) collate utf8_unicode_ci NOT NULL default '',
  `cur_timestamp` varchar(14) collate utf8_unicode_ci NOT NULL default '',
  `cur_restrictions` tinytext collate utf8_unicode_ci NOT NULL,
  `cur_counter` bigint(20) unsigned NOT NULL default '0',
  `cur_is_redirect` tinyint(1) unsigned NOT NULL default '0',
  `cur_minor_edit` tinyint(1) unsigned NOT NULL default '0',
  `cur_is_new` tinyint(1) unsigned NOT NULL default '0',
  `cur_random` double unsigned NOT NULL default '0',
  `cur_touched` varchar(14) collate utf8_unicode_ci NOT NULL default '',
  `inverse_timestamp` varchar(14) collate utf8_unicode_ci NOT NULL default '',
  UNIQUE KEY `cur_id` (`cur_id`),
  UNIQUE KEY `cur_namespace_2` (`cur_namespace`,`cur_title`),
  KEY `cur_namespace` (`cur_namespace`),
  KEY `cur_title` (`cur_title`(20)),
  KEY `cur_timestamp` (`cur_timestamp`),
  KEY `cur_random` (`cur_random`),
  KEY `name_title_timestamp` (`cur_namespace`,`cur_title`,`inverse_timestamp`),
  KEY `user_timestamp` (`cur_user`,`inverse_timestamp`),
  KEY `usertext_timestamp` (`cur_user_text`,`inverse_timestamp`),
  KEY `namespace_redirect_timestamp` (`cur_namespace`,`cur_is_redirect`,`cur_timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci PACK_KEYS=1 AUTO_INCREMENT=2560 ;

and use this query:

select cur_id, replace(cur_title,'_',' ')
     from cur
       where cur_namespace=0 
         and (length(cur_title)>4
           or cur_title regexp '\d\d\d\d')
       order by length(cur_title) desc, cur_title LIMIT 0,50;
[21 Nov 2004 0:09] MySQL Verification Team
Thank you for the bug report I was able to repeat on Linux and Windows.
Also happens for 5.0 BK source.

Below Call Stack:

>	mysqld.exe!othercase(charset_info_st * charset=0x007fe3f0, int ch=100)  Line 867 + 0xa	C
 	mysqld.exe!ordinary(parse * p=0x0457ebc8, int ch=100)  Line 911 + 0x39	C
 	mysqld.exe!p_ere_exp(parse * p=0x0457ebc8)  Line 337 + 0xe	C
 	mysqld.exe!p_ere(parse * p=0x0457ebc8, int stop=128)  Line 225 + 0x9	C
 	mysqld.exe!regcomp(regex_t * preg=0x03f8d678, const char * pattern=0x00e6f950, int cflags=7, charset_info_st * charset=0x007fe3f0)  Line 177 + 0xe	C
 	mysqld.exe!Item_func_regex::fix_fields(THD * thd=0x03f8b9c0, st_table_list * tables=0x03f8d128, Item * * ref=0x03f8d74c)  Line 2370 + 0x41	C++
 	mysqld.exe!Item_cond::fix_fields(THD * thd=0x03f8b9c0, st_table_list * tables=0x03f8d128, Item * * ref=0x03f8d7e4)  Line 1948 + 0x27	C++
 	mysqld.exe!Item_cond::fix_fields(THD * thd=0x03f8b9c0, st_table_list * tables=0x03f8d128, Item * * ref=0x03f8e3ac)  Line 1948 + 0x27	C++
 	mysqld.exe!setup_conds(THD * thd=0x03f8b9c0, st_table_list * tables=0x03f8d128, Item * * conds=0x03f8e3ac)  Line 2602 + 0x2a	C++
 	mysqld.exe!setup_without_group(THD * thd=0x03f8b9c0, Item * * ref_pointer_array=0x03f8e3e8, st_table_list * tables=0x03f8d128, List<Item> & fields={...}, List<Item> & all_fields={...}, Item * * conds=0x03f8e3ac, st_order * order=0x03f8d8e8, st_order * group=0x00000000, int * hidden_group_fields=0x03f8e324)  Line 229 + 0x11	C++
 	mysqld.exe!JOIN::prepare(Item * * * rref_pointer_array=0x03f8bbf8, st_table_list * tables_init=0x03f8d128, unsigned int wild_num=0, Item * conds_init=0x03f8d750, unsigned int og_num=2, st_order * order_init=0x03f8d8e8, st_order * group_init=0x00000000, Item * having_init=0x00000000, st_order * proc_param_init=0x00000000, st_select_lex * select_lex_arg=0x03f8bb0c, st_select_lex_unit * unit_arg=0x03f8ba0c)  Line 278 + 0x112	C++
 	mysqld.exe!mysql_select(THD * thd=0x03f8b9c0, Item * * * rref_pointer_array=0x03f8bbf8, st_table_list * tables=0x03f8d128, unsigned int wild_num=0, List<Item> & fields={...}, Item * conds=0x03f8d750, unsigned int og_num=2, st_order * order=0x03f8d8e8, st_order * group=0x00000000, Item * having=0x00000000, st_order * proc_param=0x00000000, unsigned long select_options=8669696, select_result * result=0x03f8d9d8, st_select_lex_unit * unit=0x03f8ba0c, st_select_lex * select_lex=0x03f8bb0c)  Line 1564 + 0x34	C++
 	mysqld.exe!handle_select(THD * thd=0x03f8b9c0, st_lex * lex=0x03f8ba00, select_result * result=0x03f8d9d8)  Line 193 + 0x87	C++
 	mysqld.exe!mysql_execute_command(THD * thd=0x03f8b9c0)  Line 2006 + 0x11	C++
 	mysqld.exe!mysql_parse(THD * thd=0x03f8b9c0, char * inBuf=0x03f8cd68, unsigned int length=223)  Line 4061 + 0x9	C++
 	mysqld.exe!dispatch_command(enum_server_command command=COM_QUERY, THD * thd=0x03f8b9c0, char * packet=0x03f80081, unsigned int packet_length=224)  Line 1466 + 0x1d	C++
 	mysqld.exe!do_command(THD * thd=0x03f8b9c0)  Line 1280 + 0x31	C++
 	mysqld.exe!handle_one_connection(void * arg=0x03f8b9c0)  Line 1024 + 0x9	C++
 	mysqld.exe!pthread_start(void * param=0x03f8b278)  Line 63 + 0x7	C
 	mysqld.exe!_threadstart(void * ptd=0x03f8b2b0)  Line 173 + 0xd	C
 	kernel32.dll!7c80b50b() 	
 	kernel32.dll!7c8399f3()
[7 Feb 2005 9:47] Sergei Glukhov
Verified on latest 4.1/5.0 trees. Can't repeat
[7 Feb 2005 15:13] MySQL Verification Team
I can confirm what Gluh found. I am not anymore for to crash the
server with a Windows server build with latest BK source.