This bug is actually two. The first one manifests itself on an EXPLAIN
SELECT query with nested subqueries that employs the filesort algorithm.
The whole SELECT under explain is marked as UNCACHEABLE_EXPLAIN to preserve
some temporary structures for explain. As a side-effect of this values of
nested subqueries weren't cached and subqueries were re-evaluated many
times. Each time buffer for filesort was allocated but wasn't freed because
freeing occurs at the end of topmost SELECT. Thus all available memory was
eaten up step by step and OOM event occur.
The second bug manifests itself on SELECT queries with conditions where
a subquery result is compared with a key field and the subquery itself also
has such condition. When a long chain of such nested subqueries is present
the stack overrun occur. This happens because at some point the range optimizer
temporary puts the PARAM structure on the stack. Its size if about 8K and
the stack is exhausted very fast.

Now the subselect_single_select_engine::exec function allows subquery result
caching when the UNCACHEABLE_EXPLAIN flag is set.
Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun
function for stack checking purposes to prevent server crash.


mysql-test/t/subselect.test:
  Added a test case for the bug#31048: Many nested subqueries may cause server crash.
mysql-test/r/subselect.result:
  Added a test case for the bug#31048: Many nested subqueries may cause server crash.
sql/opt_range.cc:
  Bug#31048: Many nested subqueries may cause server crash.
  Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun
  function for stack checking purposes to preven server crash.
sql/item_subselect.cc:
  Bug31048: Many nested subqueries may cause server crash.
  Now the subselect_single_select_engine::exec function allows subquery result
  caching when the UNCACHEABLE_EXPLAIN flag is set.