MySQL Bugs: #14235: Segfault during SELECT

Bug #14235	Segfault during SELECT
Submitted:	23 Oct 2005 5:46	Modified:	25 Nov 2005 11:36
Reporter:	Arjen Lentz	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.13	OS:	Linux (SuSE Linux 9.0)
Assigned to:		CPU Architecture:	Any

Description:
mysqld got signal 11

thd=0x8a1fa58
Cannot determine thread, fp=0xbe5fea68, backtrace may not be correct.

Stack trace:

0x8154e90 handle_segfault + 416
0x40060bb1 _end + 934303489
0x833fa69 _mi_pack_key + 57
0x833b2a5 mi_rkey + 165
0x81fb21c _ZN9ha_myisam10index_readEPcPKcj16ha_rkey_function + 76
0x81f72ac _ZN7handler16read_range_firstEPK12st_key_rangeS2_bb + 156
0x81f7119 _ZN7handler22read_multi_range_firstEPP18st_key_multi_rangeS1_jbP17st_handler_buffer + 137
0x81ebbd8 _ZN18QUICK_RANGE_SELECT8get_nextEv + 280
0x81f17e8 _Z8rr_quickP14st_read_record + 24
0x81a7ff7 _Z21join_init_read_recordP13st_join_table + 87
0x81a6f80 _Z10sub_selectP4JOINP13st_join_tableb + 272
0x81a7444 _Z20flush_cached_recordsP4JOINP13st_join_tableb + 420
0x81a6e38 _Z16sub_select_cacheP4JOINP13st_join_tableb + 216
0x81a6fb7 _Z10sub_selectP4JOINP13st_join_tableb + 327
0x81a6fb7 _Z10sub_selectP4JOINP13st_join_tableb + 327
0x81a6fb7 _Z10sub_selectP4JOINP13st_join_tableb + 327
0x81a6c74 _Z9do_selectP4JOINP4ListI4ItemEP8st_tableP9Procedure + 596
0x8197eee _ZN4JOIN4execEv + 1278
0x819915e _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_mP13select_resultP18st_select_lex_unitP13st_sel + 286
0x8195830 _Z13handle_selectP3THDP6st_lexP13select_resultm + 304
0x8169b99 _Z21mysql_execute_commandP3THD + 809
0x8170a80 _Z11mysql_parseP3THDPcj + 304
0x81681eb _Z16dispatch_command19enum_server_commandP3THDPcj + 1131
0x8167d2d _Z10do_commandP3THD + 141
0x816722b handle_one_connection + 555
0x4005a0f0 _end + 934276160
0x401f0c77 _end + 935942087
New value of fp=(nil) failed sanity check, terminating stack trace!

thd->query at 0x8a4f5d8 = SELECT DISTINCT bizbranches.biz_ref, pc_au.pcode_id,pc_au.locality, biznames.name,biznames.description FROM pc_au,bizcontacts,cat_bizlist,biznames,bizbranches,bizlist WHERE pc_au.loc_ref IN (4,10,11,20,21,22,23) AND pc_au.pcode_id = bizcontacts.pcode_ref AND cat_bizlist.cat_ref IN (3,6,7,8,26,27,28,29,30,66) AND cat_bizlist.biz_ref = biznames.biz_ref AND (bizbranches.biz_ref = bizcontacts.biz_ref OR biznames.biz_ref = bizcontacts.biz_ref) AND (bizbranches.biz_ref = bizlist.biz_id AND bizlist.parent_ref = biznames.biz_ref) ORDER BY pc_au.locality,pc_au.pcode,biznames.name

thd->thread_id=1 (it's the only connection at this point)

How to repeat:
It's a pretty evil old query in an old app and I can't easily extract a testcase from the dataset. Please let me know if you can't work it out from the above info.

Thank you for a bug report. 

Please, provide the SHOW CREATE TABLE resutls for the tables used in that query (pc_au, bizcontacts, cat_bizlist, biznames, bizbranches, bizlist). I need them to be able to test on the current -BK sources.

The number of rows in each of the tables and your my.cnf content will be useful too.

Re-tested with regular 5.0.13 (not glibc23 version), problem remained.
Re-tested with 5.0.15, problem disappeared.
I'll keep an eye on this and re-file or re-open the bug if I spot it again with this app, and will then provide complete sample data to assist with reproducing the issue.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".