Comment 7 for bug 1182572

Upstream claims to have fixed this in 5.5.36 and 5.6.16:

5.5$ bzr log -r 4569
------------------------------------------------------------
revno: 4569
committer: Arun Kuruvila <email address hidden>
branch nick: mysql-5.5
timestamp: Mon 2013-12-30 11:39:55 +0530
message:
  Bug #16324629 : SERVER CRASHES ON UPDATE/JOIN FEDERATED +
                  LOCAL TABLE WHEN ONLY 1 LOCAL ROW

  Description: When updating a federated table with UPDATE...
  JOIN, the server consistently crashes with Signal 11 when
  only 1 row exists in the local table involved in the join
  and that 1 row can be joined with a row in the federated
  table.

  Analysis: Interaction between the federated engine and the
  optimizer results in the crash. In our scenario, ie, local
  table having only one row, the program is following a
  different path because the table is treated as a constant
  table by the join optimizer. So in this scenario
  "index_read()" is happening in the prepare phase,
  since optimizer plan is different for constant table joins.
  In this case, "index_read_idx_map()" (inside handler.cc) is
  calling "index_read()" and inside "index_read()", matching
  rows are fetched and "stored_result" gets populated by
  calling "store_result()". And just after "index_read()",
  "index_end()" function is called. And in the "index_end()",
  its freeing the "stored_result" by calling "free_result()".
  So when it reaches the execution phase, in "position()"
  function, we are getting assertion at
  "DBUG_ASSERT(stored_result);". In all other scenarios (ie,
  table with more than 1 row), optimizer plan is different
  and "index_read()" is happening in the execution phase.

  Fix: So my fix is to have a separate ha_federated member
  function for "index_read_idx_map()" which will handle
  federated engine separately. So that position() will be
  called before index_end() call in constant table scenario.