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().


sql/sql_lex.h:
  Add st_select_lex::cleanup, a counterpart of st_select_lex_unit::cleanup()
sql/sql_select.cc:
  - remove two unused arguments from return_zero_rows
  - split JOIN::join_free and JOIN::cleanup to recursive and non-recursive
    parts.
  - note, the assert in JOIN::join_free _does_ fail in having.test.
    We have two options: a) propagate `full' flag to the nested joins.
    We did it before, and this patch didn't change it. If so, we 
    can end up cleaning up an uncacheable JOIN (that is, the join that
    we might need again).
    b) evaluate own 'full' flag on every level. In this case, we might
    end up with tables freed in mysql_unlock_read_tables, but not
    cleaned up properly, and this may be even worse. The test suite
    passes with both approaches, but not with the assert.
sql/sql_select.h:
  - declarations for JOIN::cleanup() and JOIN::join_free()
sql/sql_union.cc:
  Add st_select_lex::cleanup, a counterpart of st_select_lex_unit::cleanup():
  move the recursive part of JOIN::cleanup to it.

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

mysql-test/r/view.result:
  using encrypt & substring_index in view
mysql-test/t/view.test:
  using encrypt & substring_index in view
sql/item_strfunc.h:
  fixed encrypt() print

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

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


sql/sql_class.h:
  Auto merged

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

mysql-test/r/case.result:
  SCCS merged
mysql-test/t/case.test:
  SCCS merged
sql/item_cmpfunc.cc:
  SCCS merged

Fix for compilation failure with Forte Developer C++.


configure.in:
  Export ARFLAGS, so innobase could pick it up.
innobase/configure.in:
  Use ARFLAGS exported by parent configure script.

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).


sql/sp_head.cc:
  - use Query_arena support in sp_head::execute() as now sp_instr inherites
    from it.
sql/sp_head.h:
  - inherite sp_instr from Query_arena
sql/sql_class.cc:
  - changed the principle of Query_arena::backup_arena; free_items is now
    a member of Query_arena.
sql/sql_class.h:
  - changed the principle of Query_arena::backup_arena; free_items is now
    a member of Query_arena.
sql/sql_prepare.cc:
  free_items() is now a member of Query_arena.
sql/sql_select.cc:
  free_items() now automatically sets free_list to zero.

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

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


mysql-test/mysql-test-run.pl:
  Auto merged

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


mysql-test/mysql-test-run.pl:
  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


sql/sql_class.h:
  Auto merged

#define macro improvement


mysql-test/r/sp-security.result:
  BUG#9503: reseting correct parameters of thread after error in SP function
mysql-test/t/sp-security.test:
  BUG#9503: reseting correct parameters of thread after error in SP function
sql/item_func.cc:
  fixed environment restoring in case of error during SP function execution
sql/protocol.cc:
  added debug print
sql/sql_class.h:
  fixed #defines to force them to be alvaise in piar, and variable name made more complex for accident repeating in other code

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


sql/opt_range.cc:
  Auto merged

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

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

  Identation correction.


sql/opt_range.cc:
  Identation correction.

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

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


sql/opt_range.cc:
  Auto merged

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


sql/opt_range.cc:
  Auto merged

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


extra/yassl/taocrypt/include/runtime.hpp:
  Do not define __cxa_pure_virtual for ICC.
  Fixes "multiple definition of __cxa_pure_virtual" link failure on production.

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

BitKeeper/deleted/.del-generate-flag-images~f77476753fff8186:
  Delete: Docs/Support/generate-flag-images
Docs/Makefile.am:
  - fixed node names for the new info file
Docs/Support/generate-text-files.pl:
  - stop printing if the index was reached

  
  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.


mysql-test/r/range.result:
  - Added test for BUG#11185
  - Added missing test from 4.1. This test also tests the fix for BUG#11185.
mysql-test/t/range.test:
  - Added test for BUG#11185
  - Added missing test from 4.1. This test also tests the fix for BUG#11185.
sql/opt_range.cc:
  Added a new optimization to the range optimizer where we detect that
  an UNSIGNED field is compared with a negative constant. Depending on
  the comparison operator, we know directly that the result of the
  comparison is either TRUE or FALSE for all input values, and we need
  not check each value.
      
  This optimization is also necessary so that the index range access
  method produces correct results when comparing unsigned fields with
  negative constants.

  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.


mysql-test/t/subselect.test:
  Added a test case for bug #11487.
mysql-test/r/subselect.result:
  Added a test case for bug #11487.
sql/opt_range.cc:
  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.

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.


mysql-test/r/range.result:
  - Changed incorrect result of an old test
  - Added new results for BUG#11185
mysql-test/t/range.test:
  - Added new tests for BUG#11185
  - Deleted an old comment because now the problem is fixed
sql/opt_range.cc:
  Added a new optimization to the range optimizer where we detect that
  an UNSIGNED field is compared with a negative constant. Depending on
  the comparison operator, we know directly that the result of the
  comparison is either TRUE or FALSE for all input values, and we need
  not check each value.
  
  This optimization is also necessary so that the index range access
  method produces correct results when comparing unsigned fields with
  negative constants.