[MDEV-5103] server crashed on singular Item_equal Created: 2013-10-05  Updated: 2014-01-29  Resolved: 2013-11-23

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.4, 5.3.12, 5.5.33a
Fix Version/s: 5.5.35, 10.0.7, 5.3.13

Type: Bug Priority: Major
Reporter: roberto spadim Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux


Attachments: File MDEV-5103.sql    

 Description   

Hi guys! i got a crash from server, i don't know the query yet to reproduce the error, but i have the log, could anyone help me? i will try to find the query
the version is 10.0.3, not 10.0.4, maybe this bug was resolved in other MDEV

here the log output:

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.
 
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
 
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.
 
Server version: 10.0.3-MariaDB-log
key_buffer_size=16777216
read_buffer_size=1048576
max_used_connections=1
max_threads=102
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 227275 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x0x39ba9e8
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...
stack_bottom = 0x7f463439bed8 thread_stack 0x48000
mysys/stacktrace.c:247(my_print_stacktrace)[0xa71d19]
sql/signal_handler.cc:153(handle_fatal_signal)[0x6a54f8]
??:0(??)[0x7f4638f28670]
sql/item_cmpfunc.cc:6065(Item_equal::fix_length_and_dec())[0x6d31e5]
sql/item_cmpfunc.cc:5985(Item_equal::fix_fields(THD*, Item**))[0x6c84ce]
sql/item_cmpfunc.cc:4338(Item_cond::fix_fields(THD*, Item**))[0x6ce6b8]
sql/item_subselect.cc:2504(Item_in_subselect::inject_in_to_exists_cond(JOIN*))[0x71db68]
sql/opt_subselect.cc:5524(JOIN::choose_subquery_plan(unsigned long long))[0x65ebbb]
sql/sql_select.cc:3920(make_join_statistics)[0x4ff779]
sql/sql_select.cc:1301(JOIN::optimize_inner())[0x5cda45]
sql/sql_select.cc:1010(JOIN::optimize())[0x5cfc39]
sql/sql_lex.cc:3500(st_select_lex::optimize_unflattened_subqueries(bool))[0x582cb0]
sql/sql_select.cc:1728(JOIN::optimize_inner())[0x5ced9d]
sql/sql_select.cc:1010(JOIN::optimize())[0x5cfd2b]
sql/sql_select.cc:371(handle_select(THD*, LEX*, select_result*, unsigned long))[0x5d0814]
sql/sql_parse.cc:5044(execute_sqlcom_select)[0x584554]
sql/sql_parse.cc:2483(mysql_execute_command(THD*))[0x58ed8b]
sql/sql_parse.cc:6176(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x5916d8]
sql/sql_parse.cc:1276(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x593092]
sql/sql_connect.cc:1267(do_handle_one_connection(THD*))[0x636754]
sql/sql_connect.cc:1183(handle_one_connection)[0x6367b8]
??:0(??)[0x7f4638f20ce2]
??:0(??)[0x7f4637234a0d]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f46080008e0): is an invalid pointer
Connection ID (thread ID): 2
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off,exists_to_in=off
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
131005 11:40:26 mysqld_safe Number of processes running now: 0
131005 11:40:26 mysqld_safe mysqld restarted

found the query...

 
SELECT arquivo_id,usuario,datahora_gmt,tipo_arquivo,nome_arquivo,tamanho_arquivo FROM importacao_arquivos AS a WHERE datahora_gmt>='0000-00-00 00:00:00' AND datahora_gmt<='2013-10-07 02:59:59' AND tipo='r' AND (tipo_arquivo,arquivo_id) NOT IN (SELECT tipo_arquivo,arquivo_id FROM importacao_arquivos_datas WHERE (tipo_arquivo,arquivo_id)=(a.tipo_arquivo,a.arquivo_id)) ORDER BY arquivo_id DESC
 

attached the file of table dump

this query is the workaround i found to not crash the server, but it's wrong since it do a table scan

 
SELECT arquivo_id,usuario,datahora_gmt,tipo_arquivo,nome_arquivo,tamanho_arquivo 
FROM importacao_arquivos AS a 
WHERE datahora_gmt>='0000-00-00 00:00:00' AND datahora_gmt<='2013-10-07 02:59:59' AND 
tipo='r' 
AND (tipo_arquivo,arquivo_id) NOT IN (
	SELECT tipo_arquivo,arquivo_id FROM importacao_arquivos_datas 
	#WHERE (tipo_arquivo,arquivo_id)=(a.tipo_arquivo,a.arquivo_id)   <- removing the reference from table don't crash the server
) 
ORDER BY arquivo_id DESC



 Comments   
Comment by Elena Stepanova [ 2013-10-05 ]

Thanks, Roberto.

The test case mdev5103.test is exactly the same data and query as Roberto posted, just joined together in one MTR-ish test. It has been uploaded to FTP/private.

Comment by roberto spadim [ 2013-10-05 ]

Hi elena, could you make the content of files private? or remove the content of field
`conteudo` longblob NOT NULL,
?

Comment by Elena Stepanova [ 2013-10-05 ]

Hi Roberto,

Your attachment was public, so I assumed it was intended.
I don't think there are private attachments in JIRA. I removed mine now (and uploaded to the private FTP instead), but I cannot remove or edit yours, please check if you can.

Comment by roberto spadim [ 2013-10-05 ]

hi elena i will reattach without the data

Comment by roberto spadim [ 2013-10-05 ]

reatached without binary data

Comment by roberto spadim [ 2013-10-05 ]

Done

Comment by roberto spadim [ 2013-10-06 ]

Hi guys, anyone could reproduce it?

Comment by roberto spadim [ 2013-10-06 ]

Tested with 10.0.4, it crash the server too

Comment by Elena Stepanova [ 2013-10-06 ]

Roberto,

I already said that I uploaded your test case to the FTP, and as you can see the 'affected versions" field was updated, and the bug was assigned. Please don't worry. Additional traffic on the bug won't make it go any faster.

Comment by roberto spadim [ 2013-10-06 ]

very nice elena =) i just reported my test =)

Comment by Oleksandr Byelkin [ 2013-11-06 ]

Committed for review.

Comment by roberto spadim [ 2013-11-06 ]

nice news =)

Comment by Oleksandr Byelkin [ 2013-11-11 ]

pushed to 5.3

Comment by roberto spadim [ 2013-11-12 ]

nice good news, thanks guys

2013/11/12 Oleksandr Byelkin (JIRA) <jira@mariadb.atlassian.net>


Roberto Spadim
SPAEmpresarial

Comment by roberto spadim [ 2013-11-18 ]

hi guys, this wasn't fixed? couldn't be pushed at 10.0.5/10.0.6?

Comment by Igor Babaev [ 2013-11-18 ]

Roberto,

The fix was incomplete. That's why I reopened the bug.

Igor

Comment by Igor Babaev [ 2013-11-23 ]

A new patch for the was pushed into the 5.3 tree.

Comment by Daniel Bartholomew [ 2014-01-29 ]

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/3984

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/2502.567.170

Comment by Daniel Bartholomew [ 2014-01-29 ]

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/2502.581.1

Generated at Thu Feb 08 07:01:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.