MySQL Bugs: #5189: Out of Memory leads to segfault

Bug #5189	Out of Memory leads to segfault
Submitted:	24 Aug 2004 20:06	Modified:	30 Jan 2006 12:45
Reporter:	Jeremy Tinley	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.0.20	OS:	Linux (Redhat Linux ES)
Assigned to:		CPU Architecture:	Any

Description:
MySQL Server 4.0.20
Red Hat Linux ES
Kernel: 2.4.21-15.0.3.ELsmp
RAM: 6GB

When executing a very large SQL query (~256KB), the server runs out of memory and crashes.  Stack trace below:

0x8070740 handle_segfault + 420
0x8247998 pthread_sighandler + 184
0x80bb7b4 __7SEL_ARGP5FieldUcPcT3UcUcUc + 24
0x80bb8ba clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 154
0x80bb90b clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 235
0x80bb8e4 clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 196
0x80bb8e4 clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 196
0x80bb90b clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 235
0x80bb8e4 clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 196
0x80bb90b clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 235
0x80bb8e4 clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 196
0x80bb90b clone__7SEL_ARGP7SEL_ARGPP7SEL_ARG + 235
0x80bbb12 clone_tree__7SEL_ARG + 30
0x80bd349 key_and__FP7SEL_ARGT0Ui + 101
0x80bd242 and_all_keys__FP7SEL_ARGT0Ui + 206
0x80bd40e key_and__FP7SEL_ARGT0Ui + 298
0x80bd0b1 tree_and__FP13st_qsel_paramP8SEL_TREET1 + 253
0x80bc266 get_mm_tree__FP13st_qsel_paramP4Item + 162
0x80bbefa test_quick_select__10SQL_SELECTP3THDUlUlUlb + 958
0x80958a1 get_quick_record_count__FP3THDP10SQL_SELECTP8st_tableUlUl + 57
0x80962f6 make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dynamic_array + 2598
0x8094427 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UlP13select_result + 2071
0x8093bd6 handle_select__FP3THDP6st_lexP13select_result + 102
0x807b2d0 mysql_execute_command__Fv + 1020
0x807ebda mysql_parse__FP3THDPcUi + 146
0x807a3d3 dispatch_command__F19enum_server_commandP3THDPcUi + 1435
0x8079e2d do_command__FP3THD + 157
0x8079669 handle_one_connection + 641
0x824514c pthread_start_thread + 220
0x827b17a thread_start + 4

How to repeat:
I have done limited testing.  So far, the only suggestion I have is to try a very large SQL query (~256KB) to see if you can repeat the issue.

Query that we used to crash server

Attachment: consortia_query.zip (application/x-zip-compressed, text), 82.52 KiB.

Hi Jeremy,

Thanks for the bug report!

Is all the available memory on the machine used?  If this is the case then the kernel will start 
killing running processes, is this what you're seeing?

If not, could you provide any help in trying to repeat the problem?  Would it be possible to get 
the query and releated table structures?

Best Regards

Just a hint: from the stack trace it is apparent that the problem in not the size of the query itself, but the size of the range tree MySQL creates in range optimizer.

You probably have a combined key of many key parts, and a range condition in where on each part of the key.

That's exactly what we have. This breaks the range optimizer then?  Should the out of memory cause a segfault?  Is there any way to adjust tuning to allow this to execute?  Is it truely a bug?

The table structure and indexes have been attached as a private attachment.

May i ask you to upload SHOW CREATE TABLE result?

Having a CREATE statement that works right away would
ease testing a lot ...

Create table attached as a file

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".

Attempting to ping this for reopening.

I beg your pardon for this bug report spent so much time without real handling. Please, try to repeat the problem with a newer version, 4.0.26 (or the last one in whatever MySQL server you are using now). Send you my.cnf content and inform about the number of rows in the table.

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".