It crashes in this line

  join_tab->tracker->r_scans++;

because join_tab->tracker==NULL. The only reason it could be NULL is that JOIN::save_explain_data() has not been called for this join.

Minimal sequence to do the crash:

create view v1 as select max(i) from t1;

create trigger t1_bi before insert on t1 for each row

  set new.i = (select * from v1) + 1;

insert into t1 values (1);

The crash happens in the INSERT command.

First, we enter:

#0 JOIN::optimize (this=0x7fffc7276088) at /home/psergey/dev-git/10.1/sql/sql_select.cc:1022
this is "select * from v1"
select_lex->select_number=2

Then, we enter
JOIN::optimize (this=0x7fffc7274470)

This is "create vew v1 as select max from t1"
select->select_number=2 (AGAIN!)

the inner JOIN::optimize() finishes, calls JOIN::save_explain_data() and saves
its plan under select_number==2.

The outer JOIN::optimizer(this=0x7fffc7276088) finishes, attepts to save its
query plan, sees that there is one already, and doesn't save.

Not saving the plan causes tracker counters not to be created, which later causes crash.

It's generally a bad thing that two selects in the same query both have select_number=2. However, attempting to fix this may open a can of worms.

What if I de-coupled query plan saving and creation of counters instead? They are logically two different tasks.

The problem with the above approach is that the counters belong to the Explain data structures.

We could have a separate function which walks through both JOIN_TABs and
Explain data structures and sets JOIN_TABs' pointers to point to the EXPLAIN
data structure..

But it won't help. The point is, here we have a situation where there are two
JOIN objects, and one Explain_select object. Attempt to set both of them to
point to counters in Explain_select is bound to fail (what if these two joins
have different numbers of tables?)

After a long discussion with sanja, came up with a way to avoid two select_lex objects having the same select_number.