The top query ends with:
HAVING  alias1 . col_int_nokey  IN ( SELECT 2 FROM DUAL ) ;

JOIN::prepare on the query owning HAVING saves select_lex->having to
having_for_explain.
Item_in_subselect::fix_fields (select_lex->having->fix_fields) replaces
select_lex->having with "alias1 . col_int_nokey=2".
SELECT 2 FROM DUAL becomes "detached", "orphan" (unit::exclude_level())),
it won't be optimized, which is normal.
having_for_explain is not changed, still points to item_in_subselect (bad).
Later JOIN::optimize on the query owning HAVING wants to print this query,
(in simplify_joins),
select_lex::print gets HAVING from having_for_explain (stale item)
and crashes when it reads master_unit() of 'SELECT 2 FROM DUAL' (NULL pointer,
because 'detached' query).
In trunk this does not happen because of WL7082: simplify_joins moved to the
prepare phase, so join->optimized is false then, so select_lex::print uses
select_lex::having which is correct
(however, this bug has put me on the track of variant queries which do crash
trunk, so a trunk-specific patch will be submitted; the present patch will not
be put in trunk).

Fix (conservative): update having_for_explain after fix_fields.
Additionnally, a related robustness fix is added in select_lex::print
(back-ported from trunk).