cskristof,
Could you please attach your cnf file(s) and paste the output of

SHOW CREATE TABLE feature;

SHOW INDEX IN feature;

SHOW CREATE TABLE compound;

SHOW INDEX IN compound;

SHOW TRIGGERS LIKE 'feature';

-- ... and also 

# SHOW CREATE TRIGGER .... ;

-- for each trigger that the previous command returns, and 

# SHOW CREATE TABLE ... ;

# SHOW INDEX IN ... ;

-- for each table these triggers use

It would be even better if you could provide the schema/data dump. You can upload it to ftp.askmonty.org/private.

I just uploaded a full database dump to the ftp server, with name: MDEV-10050.sql.

cskristof, thanks a lot.
The request for the cnf file(s) still holds, though, could you please attach or paste them as well?
Thanks.

Hi!
I uploaded the config file as MDEV-10050_my.ini

kcsabi,

Thanks for the report and all the information.
I've run numerous tests trying to reproduce the problem, but couldn't get the crash so far.
There is definitely a bug here, so the report will stay open, maybe something else comes up – somebody encounters the problem and we can compare the circumstances, or we manage to reproduce it locally.

How often does it happen? Could you, by any chance, enable the general log for a while, so that we can see what else is going on right before and during the crash?
If there is a heavy activity on the server, you probably shouldn't do it, as the general log can slow it down a bit, but if the server is not overly busy, it could help.

I do have the same problem as described in this report.
Please tell me which information you need to analyze the problem.

-------------------------
This is from my error.log:

2016-05-25 9:23:45 8212 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-05-25 9:23:45 8212 [Note] InnoDB: The InnoDB memory heap is disabled
2016-05-25 9:23:45 8212 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2016-05-25 9:23:45 8212 [Note] InnoDB: Memory barrier is not used
2016-05-25 9:23:45 8212 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-05-25 9:23:45 8212 [Note] InnoDB: Using generic crc32 instructions
2016-05-25 9:23:45 8212 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-05-25 9:23:45 8212 [Note] InnoDB: Completed initialization of buffer pool
2016-05-25 9:23:45 8212 [Note] InnoDB: Highest supported file format is Barracuda.
2016-05-25 9:23:48 8212 [Note] InnoDB: 128 rollback segment(s) are active.
2016-05-25 9:23:48 8212 [Note] InnoDB: Waiting for purge to start
2016-05-25 9:23:48 8212 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.29-76.2 started; log sequence number 8923647626
2016-05-25 9:23:49 3572 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-05-25 9:23:49 8212 [Note] Plugin 'FEEDBACK' is disabled.
2016-05-25 9:23:49 8212 [Note] Server socket created on IP: '::'.
2016-05-25 9:23:49 8212 [Note] C:\Program Files\MariaDB 10.1\bin\mysqld.exe: ready for connections.
Version: '10.1.14-MariaDB' socket: '' port: 3306 mariadb.org binary distribution
2016-05-25 9:25:56 11564 [Note] C:\Program Files\MariaDB 10.1\bin\mysqld.exe: Normal shutdown

2016-05-25 9:25:56 11564 [Note] Event Scheduler: Purging the queue. 0 events
2016-05-25 9:25:57 10320 [Note] InnoDB: FTS optimize thread exiting.
2016-05-25 9:25:57 11564 [Note] InnoDB: Starting shutdown...
2016-05-25 9:25:58 11564 [Note] InnoDB: Shutdown completed; log sequence number 8923692581
2016-05-25 9:25:58 11564 [Note] C:\Program Files\MariaDB 10.1\bin\mysqld.exe: Shutdown complete

2016-05-25 9:25:59 3132 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-05-25 9:25:59 3132 [Note] InnoDB: The InnoDB memory heap is disabled
2016-05-25 9:25:59 3132 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2016-05-25 9:25:59 3132 [Note] InnoDB: Memory barrier is not used
2016-05-25 9:25:59 3132 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-05-25 9:25:59 3132 [Note] InnoDB: Using generic crc32 instructions
2016-05-25 9:25:59 3132 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2016-05-25 9:25:59 3132 [Note] InnoDB: Completed initialization of buffer pool
2016-05-25 9:25:59 3132 [Note] InnoDB: Highest supported file format is Barracuda.
2016-05-25 9:26:02 3132 [Note] InnoDB: 128 rollback segment(s) are active.
2016-05-25 9:26:02 3132 [Note] InnoDB: Waiting for purge to start
2016-05-25 9:26:02 3132 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.29-76.2 started; log sequence number 8923692581
2016-05-25 9:26:02 13116 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-05-25 9:26:02 3132 [Note] Plugin 'FEEDBACK' is disabled.
2016-05-25 9:26:02 3132 [Note] Server socket created on IP: '::'.
2016-05-25 9:26:02 3132 [Note] C:\Program Files\MariaDB 10.1\bin\mysqld.exe: ready for connections.
Version: '10.1.14-MariaDB' socket: '' port: 3306 mariadb.org binary distribution

*160525 15:17:47 [ERROR] mysqld got exception 0xc0000005 ;
*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 https://mariadb.com/kb/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.1.14-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=30
max_threads=1001
thread_count=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2311978 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0xb4a57724f8
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...
mysqld.exe!Item_in_subselect::fix_fields()[item_subselect.cc:3171]
mysqld.exe!Item_in_optimizer::fix_fields()[item_cmpfunc.cc:1352]
mysqld.exe!Item_func::fix_fields()[item_func.cc:208]
mysqld.exe!Item_func_not::fix_fields()[item_cmpfunc.cc:5806]
mysqld.exe!Item_cond::fix_fields()[item_cmpfunc.cc:4529]
mysqld.exe!Item_cond::fix_fields()[item_cmpfunc.cc:4529]
mysqld.exe!setup_conds()[sql_base.cc:8630]
mysqld.exe!setup_without_group()[sql_select.cc:646]
mysqld.exe!JOIN::prepare()[sql_select.cc:799]
mysqld.exe!mysql_select()[sql_select.cc:3431]
mysqld.exe!handle_select()[sql_select.cc:384]
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:5894]
mysqld.exe!mysql_execute_command()[sql_parse.cc:2960]
mysqld.exe!mysql_open_cursor()[sql_cursor.cc:141]
mysqld.exe!sp_cursor::open()[sp_rcontext.cc:459]
mysqld.exe!sp_instr_copen::exec_core()[sp_head.cc:3811]
mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core()[sp_head.cc:2979]
mysqld.exe!sp_instr_copen::execute()[sp_head.cc:3797]
mysqld.exe!sp_head::execute()[sp_head.cc:1317]
mysqld.exe!sp_head::execute_trigger()[sp_head.cc:1646]
mysqld.exe!Table_triggers_list::process_triggers()[sql_trigger.cc:2177]
mysqld.exe!fill_record_n_invoke_before_triggers()[sql_base.cc:9014]
mysqld.exe!select_insert::store_values()[sql_insert.cc:3749]
mysqld.exe!select_insert::send_data()[sql_insert.cc:3683]
mysqld.exe!end_send()[sql_select.cc:19394]
mysqld.exe!evaluate_join_record()[sql_select.cc:18484]
mysqld.exe!sub_select()[sql_select.cc:18258]
mysqld.exe!do_select()[sql_select.cc:17913]
mysqld.exe!JOIN::exec_inner()[sql_select.cc:3228]
mysqld.exe!JOIN::exec()[sql_select.cc:2519]
mysqld.exe!mysql_select()[sql_select.cc:3453]
mysqld.exe!handle_select()[sql_select.cc:384]
mysqld.exe!mysql_execute_command()[sql_parse.cc:4002]
mysqld.exe!Prepared_statement::execute()[sql_prepare.cc:4269]
mysqld.exe!Prepared_statement::execute_loop()[sql_prepare.cc:3901]
mysqld.exe!mysql_sql_stmt_execute()[sql_prepare.cc:3034]
mysqld.exe!mysql_execute_command()[sql_parse.cc:2972]
mysqld.exe!sp_instr_stmt::exec_core()[sp_head.cc:3215]
mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core()[sp_head.cc:2979]
mysqld.exe!sp_instr_stmt::execute()[sp_head.cc:3131]
mysqld.exe!sp_head::execute()[sp_head.cc:1317]
mysqld.exe!sp_head::execute_procedure()[sp_head.cc:2104]
mysqld.exe!do_execute_sp()[sql_parse.cc:2405]
mysqld.exe!mysql_execute_command()[sql_parse.cc:5253]
mysqld.exe!mysql_parse()[sql_parse.cc:7319]
mysqld.exe!dispatch_command()[sql_parse.cc:1489]
mysqld.exe!do_command()[sql_parse.cc:1107]
mysqld.exe!threadpool_process_request()[threadpool_common.cc:239]
mysqld.exe!io_completion_callback()[threadpool_win.cc:568]
KERNEL32.DLL!GetThreadTimes()
ntdll.dll!RtlCheckTokenMembershipEx()
ntdll.dll!RtlTryEnterCriticalSection()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0xb4a5ad3ac0): INSERT INTO DFIL SELECT * FROM temp_DFIL
Connection ID (thread ID): 2426
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=on,exists_to_in=on

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.

ThomasHuppertz,

Is it reliably reproducible if you run the same statement (that is, if you can afford trying given the risk of the crash).
The statement in the log is apparently also a part of a trigger. If possible, please provide the output of

SHOW CREATE TABLE <table name>;

-- or

SHOW CREATE VIEW <view name>;

SHOW INDEX IN <table name>;

SHOW TRIGGERS LIKE '<table name>';

SHOW CREATE TRIGGER <trigger name>;

for all involved objects, starting from the table which this trigger belongs to. If you can provide the datadump, it will be even better.
Please also attach your cnf file.
If you have the general log enabled and can locate the statement which triggered the trigger and surrounding queries, it could also help.
Whatever information you are willing to share but don't want to do it publicly, you can upload to ftp.askmonty.org/private.

I will try to compare it with what we received from cskristof, maybe it will give some clues.

I have added the requested information.
The crash is not reproducable and happens from time to time.

Do you want a datadump from the complete database?

General log is enabled now, but was not at the time of the last crash...

My version is: 10.1.14

ThomasHuppertz, thanks a lot.

If you can provide the dump, I certainly want it. When it comes to bugs which are not reproducible reliably, I generate a randomized test load and run it on the data. I did so with the data cskristof provided, but didn't get the crash, maybe I'll be luckier with yours.
Also, thanks for enabling the general log, it might help – if nothing else, I'll be able to fine-tune the test load to types of queries which are actually run on your server.

1. I have uploaded the installation Skript to ftp://ftp.askmonty.org/private
it´s name is: mysql_install.sql

2. I have also a crash dump file from an older Maria DB Server 10.1.8 with the same problem. Are you intrested in this?
The problem is .... it´s about 4GB data ... how to transfer it?

3. I have also uploaded ccc_dump.dmp to ftp://ftp.askmonty.org/private
I think the crash happens during the call of the procedure:

CCC_START_EDIT
e.g.
call CCC_START_EDIT('AGGR',5717,1461,12417,@conflictingAdminID); select @conflictingAdminID

ThomasHuppertz, thank you. I'll start looking at the data right away.

Regarding the coredump, it's fine to upload it to the same ftp.askmonty.org/private if you yourself are okay with uploading such a big file; but it only makes sense if you either have the mysqld binary with which it was produced, or remember from which package it was installed, if it was one of packages provided by MariaDB.
Alternatively, if you can't upload it, maybe you could get the output of gdb --batch --eval-command="thread apply all bt" and gdb --batch --eval-command="thread apply all bt full" – those will be small enough.

Note that the stack trace provided by ThomasHuppertz and the stack trace in the bug description point at the same place:

bool Item_in_subselect::fix_fields(THD *thd_arg, Item **ref)

{

  uint outer_cols_num;

  List<Item> *inner_cols;

  char const *save_where= thd->where;

and it seems that THD pointer is invalid, which causes a crash.

Looking at stack trace #1:

• is using Thread Pool
• is running a prepared statement
• the statement runs a single-table DELETE command
• which executes a trigger
• the trigger has another DELETE command
• which uses an IN-subquery
  and we crash when doing name resolution in the subquery.

I suppose, the query that's printed after the stack trace is the query
that is executed by the trigger. there is an IN-subquery int the WHERE, that
matches.

Stack trace #2 :

• is using Thread Pool
• is running a query directly (not through a prepared statement)
• the query is a "CALL sp" statement
• it runs an INSERT ... SELECT
• which runs a trigger
• which opens a cursor for a query that uses a NOT IN (SELECT ...) construct

1. Unfortunally i work with Visual Studio (not gdb).* I am able to debug the dump * file and can step through all of the function calls, because I do have the corresponding pdb file (its an official maria 10.1.8 release).

2. I have upload the crash dump to the ftp server. filename: mysqld.exe.3640.dmp and the pdb filename: mysqld_10_1_8.pdb file

The stack trace will look like this:

> mysqld.exe!Item_in_subselect::fix_fields(THD * thd_arg, Item * * ref) Line 3159 C++

  mysqld.exe!Item_func::fix_fields(THD * thd, Item * * ref) Line 208 C++

  mysqld.exe!Item_func_not::fix_fields(THD * thd, Item * * ref) Line 5625 C++

  mysqld.exe!Item_cond::fix_fields(THD * thd, Item * * ref) Line 4348 C++

  mysqld.exe!Item_cond::fix_fields(THD * thd, Item * * ref) Line 4348 C++

  mysqld.exe!setup_conds(THD * thd, TABLE_LIST * tables, List<TABLE_LIST> & leaves, Item * * conds) Line 8704 C++

  mysqld.exe!setup_without_group(THD * thd, Item * * ref_pointer_array, TABLE_LIST * tables, List<TABLE_LIST> & leaves, List<Item> & fields, List<Item> & all_fields, Item * * conds, st_order * order, st_order * group, bool * hidden_group_fields, unsigned int * reserved) Line 632 C++

  mysqld.exe!JOIN::prepare(Item * * * rref_pointer_array, TABLE_LIST * tables_init, unsigned int wild_num, Item * conds_init, unsigned int og_num, st_order * order_init, bool skip_order_by, st_order * group_init, Item * having_init, st_order * proc_param_init, st_select_lex * select_lex_arg, st_select_lex_unit * unit_arg) Line 785 C++

  mysqld.exe!mysql_select(THD * thd, Item * * * rref_pointer_array, TABLE_LIST * tables, unsigned int wild_num, List<Item> & fields, Item * conds, unsigned int og_num, st_order * order, st_order * group, Item * having, st_order * proc_param, unsigned __int64 select_options, select_result * result, st_select_lex_unit * unit, st_select_lex * select_lex) Line 3421 C++

  mysqld.exe!handle_select(THD * thd, LEX * lex, select_result * result, unsigned long setup_tables_done_option) Line 371 C++

  mysqld.exe!execute_sqlcom_select(THD * thd, TABLE_LIST * all_tables) Line 5867 C++

  mysqld.exe!mysql_execute_command(THD * thd) Line 2962 C++

  mysqld.exe!mysql_open_cursor(THD * thd, select_result * result, Server_side_cursor * * pcursor) Line 141 C++

  mysqld.exe!sp_cursor::open(THD * thd) Line 459 C++

  mysqld.exe!sp_instr_copen::exec_core(THD * thd, unsigned int * nextp) Line 3740 C++

  mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core(THD * thd, unsigned int * nextp, bool open_tables, sp_instr * instr) Line 2916 C++

  mysqld.exe!sp_instr_copen::execute(THD * thd, unsigned int * nextp) Line 3726 C++

  mysqld.exe!sp_head::execute(THD * thd, bool merge_da_on_success) Line 1317 C++

  mysqld.exe!sp_head::execute_trigger(THD * thd, const st_mysql_lex_string * db_name, const st_mysql_lex_string * table_name, st_grant_info * grant_info) Line 1646 C++

  mysqld.exe!Table_triggers_list::process_triggers(THD * thd, trg_event_type event, trg_action_time_type time_type, bool old_row_is_record1) Line 2151 C++

  mysqld.exe!fill_record_n_invoke_before_triggers(THD * thd, TABLE * table, List<Item> & fields, List<Item> & values, bool ignore_errors, trg_event_type event) Line 8876 C++

  mysqld.exe!mysql_insert(THD * thd, TABLE_LIST * table_list, List<Item> & fields, List<List<Item> > & values_list, List<Item> & update_fields, List<Item> & update_values, enum_duplicates duplic, bool ignore) Line 900 C++

  mysqld.exe!mysql_execute_command(THD * thd) Line 3898 C++

  mysqld.exe!mysql_parse(THD * thd, char * rawbuf, unsigned int length, Parser_state * parser_state) Line 7270 C++

  mysqld.exe!dispatch_command(enum_server_command command, THD * thd, char * packet, unsigned int packet_length) Line 1491 C++

  mysqld.exe!do_command(THD * thd) Line 1110 C++

  mysqld.exe!threadpool_process_request(THD * thd) Line 233 C++

  mysqld.exe!io_completion_callback(_TP_CALLBACK_INSTANCE * instance, void * context, void * overlapped, unsigned long io_result, unsigned __int64 nbytes, _TP_IO * io) Line 568 C++

  kernel32.dll!BasepTpIoCallback() Unknown

Checking where Item_subselect::thd is set:

• In Item_subselect::Item_subselect constructor
• In Item_subselect::init ( thd= unit->thd call)
• In Item_subselect::fix_fields ( engine->set_thd((thd_= thd_param)); call)

Note that the mentioned ctor is the only Item_subselect constructor, so the case of thd being never assigned is ruled out.

The problem is easy to observe.
1. Load the dataset from the provided MDEV-10050.sql file
2. Run select * from compound and pick two id values (let's call them $VAL1 and $VAL2) from query output
3. Re-start the server

Then, connect with client #1 and run this:

 delete from compound where id=$VAL1;

Observe execution to touch these locations:

  Breakpoint 1, Item_subselect::Item_subselect (this=0x7fffc890f958, thd_arg=0x7fffd1adb070) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:57

  Breakpoint 2, Item_subselect::init (this=0x7fffc890f958, select_lex=0x7fffc8823bf8, result=0x7fffc890fae8) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:83

  Breakpoint 1, Item_subselect::Item_subselect (this=0x7fffc8923958, thd_arg=0x7fffd1adb070) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:57

  Breakpoint 2, Item_subselect::init (this=0x7fffc8923958, select_lex=0x7fffc891abf8, result=0x7fffc8923ae8) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:83

  Breakpoint 5, Item_in_subselect::fix_fields (this=0x7fffc890f958, thd_arg=0x7fffd1adb070, ref=0x7ffff7f5f938) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:3172

  Breakpoint 3, Item_subselect::fix_fields (this=0x7fffc890f958, thd_param=0x7fffd1adb070, ref=0x7ffff7f5f938) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:233

  Breakpoint 4, Item_in_optimizer::fix_fields (this=0x7fffc89145c8, thd=0x7fffd1adb070, ref=0x7ffff7f5f938) at /home/psergey/dev-git/10.1/sql/item_cmpfunc.cc:1336

  Breakpoint 5, Item_in_subselect::fix_fields (this=0x7fffc890f958, thd_arg=0x7fffd1adb070, ref=0x7fffc8914658) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:3172

  Breakpoint 3, Item_subselect::fix_fields (this=0x7fffc890f958, thd_param=0x7fffd1adb070, ref=0x7fffc8914658) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:233

Note thd=0x7fffd1adb070..

Now, connect with another client, and run:

thread2> delete from compound where id=$VAL2;

One can see:

  Breakpoint 4, Item_in_optimizer::fix_fields (this=0x7fffc89145c8, thd=0x7fffd1ae1070, ref=0x7ffff7f15938) at /home/psergey/dev-git/10.1/sql/item_cmpfunc.cc:1336

  ...

  Item_in_optimizer::fix_left (this=0x7fffc89145c8, thd=0x7fffd1ae1070) at /home/psergey/dev-git/10.1/sql/item_cmpfunc.cc:1245

  Breakpoint 5, Item_in_subselect::fix_fields (this=0x7fffc890f958, thd_arg=0x7fffd1ae1070, ref=0x7fffc8914658) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:3172

...
Note the new THD value: 0x7fffd1ae1070.
Now, we are at:

(gdb) wher

  #0  Item_in_subselect::fix_fields (this=0x7fffc890f958, thd_arg=0x7fffd1ae1070, ref=0x7fffc8914658) at /home/psergey/dev-git/10.1/sql/item_subselect.cc:3173

  #1  0x0000555555c8ded2 in Item_in_optimizer::fix_fields (this=0x7fffc89145c8, thd=0x7fffd1ae1070, ref=0x7ffff7f15938) at /home/psergey/dev-git/10.1/sql/item_cmpfunc.cc:1352

  #2  0x00005555559c5dce in setup_conds (thd=0x7fffd1ae1070, tables=0x7fffc8823510, leaves=..., conds=0x7ffff7f15938) at /home/psergey/dev-git/10.1/sql/sql_base.cc:8629

  #3  0x0000555555dc09fb in mysql_prepare_delete (thd=0x7fffd1ae1070, table_list=0x7fffc8823510, wild_num=0, field_list=..., conds=0x7ffff7f15938) at /home/psergey/dev-git/10.1/sql/sql_delete.cc:770

  #4  0x0000555555dbee14 in mysql_delete (thd=0x7fffd1ae1070, table_list=0x7fffc8823510, conds=0x7fffc89145c8, order_list=0x7fffc8908a88, limit=18446744073709551615, options=0, result=0x0) at /home/psergey/dev-git/10.1/sql/sql_delete.cc:275

  #5  0x0000555555a24271 in mysql_execute_command (thd=0x7fffd1ae1070) at /home/psergey/dev-git/10.1/sql/sql_parse.cc:4092

  #6  0x0000555555da7680 in sp_instr_stmt::exec_core (this=0x7fffc890fb50, thd=0x7fffd1ae1070, nextp=0x7ffff7f16ca4) at /home/psergey/dev-git/10.1/sql/sp_head.cc:3213

  #7  0x0000555555da6dae in sp_lex_keeper::reset_lex_and_exec_core (this=0x7fffc890fb90, thd=0x7fffd1ae1070, nextp=0x7ffff7f16ca4, open_tables=false, instr=0x7fffc890fb50) at /home/psergey/dev-git/10.1/sql/sp_head.cc:2979

  #8  0x0000555555da7382 in sp_instr_stmt::execute (this=0x7fffc890fb50, thd=0x7fffd1ae1070, nextp=0x7ffff7f16ca4) at /home/psergey/dev-git/10.1/sql/sp_head.cc:3129

  #9  0x0000555555da2c48 in sp_head::execute (this=0x7fffc8822088, thd=0x7fffd1ae1070, merge_da_on_success=false) at /home/psergey/dev-git/10.1/sql/sp_head.cc:1317

  #10 0x0000555555da379d in sp_head::execute_trigger (this=0x7fffc8822088, thd=0x7fffd1ae1070, db_name=0x7fffc88397b8, table_name=0x7fffc88397c8, grant_info=0x7fffc889ef10) at /home/psergey/dev-git/10.1/sql/sp_head.cc:1646

  #11 0x0000555555af18e9 in Table_triggers_list::process_triggers (this=0x7fffc889ecc0, thd=0x7fffd1ae1070, event=TRG_EVENT_DELETE, time_type=TRG_ACTION_AFTER, old_row_is_record1=false) at /home/psergey/dev-git/10.1/sql/sql_trigger.cc:2177

  #12 0x0000555555dc00d6 in mysql_delete (thd=0x7fffd1ae1070, table_list=0x7fffd1b08198, conds=0x7fffd1b08920, order_list=0x7fffd1ae53c0, limit=18446744073709551615, options=0, result=0x0) at /home/psergey/dev-git/10.1/sql/sql_delete.cc:600

  #13 0x0000555555a24271 in mysql_execute_command (thd=0x7fffd1ae1070) at /home/psergey/dev-git/10.1/sql/sql_parse.cc:4092

  #14 0x0000555555a2e594 in mysql_parse (thd=0x7fffd1ae1070, rawbuf=0x7fffd1b08088 "...", length=40, parser_state=0x7ffff7f18630) at /home/psergey/dev-git/10.1/sql/sql_parse.cc:7314

That is, we are at these lines:

  if (test_strategy(SUBS_SEMI_JOIN))

    DBUG_RETURN( !( (*ref)= new (thd_->mem_root) Item_int(thd_, 1)) );

  thd_->where= "IN/ALL/ANY subquery";

and we have:

(gdb) p thd_arg

  $24 = (THD *) 0x7fffd1ae1070

(gdb) p this->thd_

  $25 = (THD *) 0x7fffd1adb070

(the underscore is because I have renamed Item_subselect::thd to Item_subselect::thd_ )

That is, one THD is messing with THD pointer that is a left over from previous execution of the statement.

psergey, thanks a lot for the analysis!

As agreed, now sanja has enough to proceed with fixing.

cskristof, ThomasHuppertz, thank you very much for the report and the provided information, as you can see, it helped to locate the problem.

Is there any timeline for the bugfix?

yes, it is as for all 5.5 bugs several weeks ahead, but taking into account nature of the bug I'll fix it now

Problem visible also in trigger code (if put an assert in Item_subselect::fix_fields).

revision-id: 475cab835fb48c91d5cca649ab93917ec1718d75 (mariadb-5.5.50-6-g475cab8)
parent(s): a482e76e65a4fee70479e877929381c86b1ec62f
committer: Oleksandr Byelkin
timestamp: 2016-06-22 14:17:06 +0200
message:

MDEV-10050: Crash in subselect

thd should not be taken earlier then fix_field and reset on fix_fields if it is needed.

—

Sorry for the question
Is it fixed now?

I am new to JIRA and don´t know how to read the following

revision-id: 475cab835fb48c91d5cca649ab93917ec1718d75 (mariadb-5.5.50-6-g475cab8)

parent(s): a482e76e65a4fee70479e877929381c86b1ec62f

committer: Oleksandr Byelkin

timestamp: 2016-06-22 14:17:06 +0200

Yes and no.

Above is fix you can find in the mailing list and apply if you need it urgent.

But the fix should be reviewed then pushed to the repository (5.5 in this case) and then it will be merged up in the other repositories (10.0, 10.1, 10.2). In the binaries it the fix appears with new releases of the versions.

Review feedback provided over email. The patch needs to be changed.

revision-id: 79f852a069fb6ba5e18fd66ea2a24fa91c245c24 (mariadb-5.5.50-7-g79f852a)
parent(s): ef92aaf9ece92c873ae0f3448ab2274c958ba3fe
committer: Oleksandr Byelkin
timestamp: 2016-06-24 14:15:35 +0200
message:

MDEV-10050: Crash in subselect

thd should not be taken earlier then fix_field and reset on fix_fields if it is needed.

—

Ok to push.

Winn this fix be delivered with Version 10.1.15 on 2016-06-30 ?

It is now in 5.5. now I'll try to merge it in 10.0 then it should go to 10.1 and be in the release.

Update: Serg will merge, but prognosis is the same: it will get in the release.

IS version 10.2.* not affected by this bug?
Or is there no solution for this bug in version 10.2?

Do you know when the 10.1.15 will be available for download (binaries)?
I can´t find it on https://downloads.mariadb.org/mariadb/+releases/

ThomasHuppertz,

• 10.1.15 was released, but then the release was pulled because they've found an issue in it (a regression, not related to this bug). We are working on 10.1.16 with priority now. 10.1.16 will include the fix for this issue and also for the regression.
• 10.2 is likely to be affected by this bug; before the next 10.2 release there will be a 10.1->10.2 merge so this fix will be available as part of the next 10.2 release.