The reason it happened was that both, JOIN::cleanup() and JOIN::join_free(),
went over all nested joins and called cleanup/join_free for them.
For that:
- split recursive and non-recursive parts of JOIN::cleanup() and
JOIN::join_free()
- rename JOIN::cleanup to JOIN::destroy, as it actually destroys its
  argument
- move the recursive part of JOIN::cleanup to st_select_lex::cleanup
- move the non-recursive part of JOIN::join_free to the introduced
  method JOIN::cleanup().

into sanja.is.com.ua:/home/bell/mysql/bk/work-bug3-5.0

into mysql.com:/home/timka/mysql/src/5.0-virgin

into sanja.is.com.ua:/home/bell/mysql/bk/work-bug3-5.0

into mysql.com:/home/timka/mysql/src/5.0-virgin

into sanja.is.com.ua:/home/bell/mysql/bk/work-bug3-5.0

into mysql.com:/home/svoj/devel/mysql/mysql-5.0.9

into mysql.com:/opt/local/work/mysql-5.0-sp_instr

into mysql.com:/home/psergey/mysql-5.0-bug8441

into mysql.com:/home/psergey/mysql-5.0-bug8441

Fix for compilation failure with Forte Developer C++.

into mysql.com:/opt/local/work/mysql-5.0-sp_instr

  We need every instruction to have its own arena, because we want to
  track instruction's state (INITIALIZED_FOR_SP -> EXECUTED). Because of 
  `if' statements and other conditional instructions used in stored 
  procedures, not every instruction of a stored procedure gets executed 
  during the first (or even subsequent) execution of the procedure. 
  So it's better if we track the execution state of every instruction 
  independently.
  All instructions of a given procedure now also share sp_head's 
  mem_root, but keep their own free_list.
  This simplifies juggling with free Item lists in sp_head::execute.
- free_items() moved to be a member of Query_arena. 
- logic of 'backup_arena' debug member of Query_arena has been
  changed to support
  multi-backups. Until now, TRUE 'backup_arena' meant that there is
  exactly one active backup of the THD arena. Now it means simply that
  the arena is used for backup, so that we can't accidentally overwrite an 
  existing backup. This allows doing multiple backups, e.g. in
  sp_head::execute and Cursor::fetch, when THD arena is already backed up
  but we want to set yet another arena (usually the 'permanent' arena,
  to save permanent transformations/optimizations of a parsed tree).

into mysql.com:/Users/kent/mysql/bk/mysql-5.0

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-release

  Might need a restart after test with special TZ
  Removed unused argument to run_mysqltest()

into sanja.is.com.ua:/home/bell/mysql/bk/work-bug3-5.0

#define macro improvement

into mysql.com:/home/timka/mysql/src/5.0-dbg

into mysql.com:/home/svoj/devel/mysql/mysql-5.0.9

into rurik.mysql.com:/home/igor/mysql-5.0

  Identation correction.

into mysql.com:/space/my/mysql-5.0-build

into rurik.mysql.com:/home/igor/dev/mysql-5.0-0

into mysql.com:/home/psergey/mysql-5.0-back-vac-look

Fix for "multiple definition of __cxa_pure_virtual" link failure
when compiling with icc.

into mysql.com:/space/my/mysql-5.0.8-clone

  
  The source of the problem is in Field_longlong::cmp. If 'this' is
  an unsigned number, the method casts both the current value, and
  the constant that we compare with to an unsigned number. As a
  result if the constant we compare with is a negative number, it
  wraps to some unsigned number, and the comparison is incorrect.
  
  When the optimizer chooses the "range" access method, this problem
  causes handler::read_range_next to reject the current key when the
  upper bound key is a negative number because handler::compare_key
  incorrectly considers the positive and negative keys to be equal.
  
  The current patch does not correct the source of the problem in
  Field_longlong::cmp because it is not easy to propagate sign
  information about the constant at query execution time. Instead
  the patch changes the range optimizer so that it never compares
  unsiged fields with negative constants. As an added benefit,
  queries that do such comparisons will execute faster because
  the range optimizer replaces conditions like:
  (a) (unsigned_int [< | <=] negative_constant) == FALSE
  (b) (unsigned_int [> | >=] negative_constant) == TRUE
  with the corresponding constants.
  In some cases this may even result in constant time execution.

  Fixed buf #11487.
  Added a call of  QUICK_RANGE_SELECT::init to the
  QUICK_RANGE_SELECT::reset method. Without it the second
  evaluation of a subquery employing the range access failed.
subselect.result, subselect.test:
  Added a test case for bug #11487.

into mysql.com:/home/timka/mysql/src/4.1-bug-11185

into mysql.com:/home/timka/mysql/src/5.0-dbg

The source of the problem is in Field_longlong::cmp. If 'this' is
an unsigned number, the method casts both the current value, and
the constant that we compare with to an unsigned number. As a
result if the constant we compare with is a negative number, it
wraps to some unsigned number, and the comparison is incorrect.

When the optimizer chooses the "range" access method, this problem
causes handler::read_range_next to reject the current key when the
upper bound key is a negative number because handler::compare_key
incorrectly considers the positive and negative keys to be equal.

The current patch does not correct the source of the problem in
Field_longlong::cmp because it is not easy to propagate sign
information about the constant at query execution time. Instead
the patch changes the range optimizer so that it never compares
unsiged fields with negative constants. As an added benefit,
queries that do such comparisons will execute faster because
the range optimizer replaces conditions like:
(a) (unsigned_int [< | <=] negative_constant) == FALSE
(b) (unsigned_int [> | >=] negative_constant) == TRUE
with the corresponding constants.
In some cases this may even result in constant time execution.