I found three issues during the analysis:
 1. Memory leak caused by temp_buf not being freed;
 2. Memory leak caused when handling argv;
 3. Conditional jump that depended on unitialized values.

Issue #1
--------

  DESCRIPTION: when mysqlbinlog is reading from a remote location
  the event temp_buf references the incoming stream (in NET
  object), which is not freed by mysqlbinlog explicitly. On the
  other hand, when it is reading local binary log, it points to a
  temporary buffer that needs to be explicitly freed. For both
  cases, the temp_buf was not freed by mysqlbinlog, instead was
  set to 0.  This clearly disregards the free required in the
  second case, thence creating a memory leak.

  FIX: we make temp_buf to be conditionally freed depending on
  the value of remote_opt. Found out that similar fix is already
  in most recent codebases.

Issue #2 
--------

  DESCRIPTION: load_defaults is called by parse_args, and it
  reads default options from configuration files and put them
  BEFORE the arguments that are already in argc and argv. This is
  done resorting to MEM_ROOT. However, parse_args calls
  handle_options immediately after which changes argv. Later when
  freeing the defaults, pointers to MEM_ROOT won't match, causing
  the memory not to be freed:

  void free_defaults(char **argv)
  {
    MEM_ROOT ptr
    memcpy_fixed((char*) &ptr,(char *) argv - sizeof(ptr), sizeof(ptr));
    free_root(&ptr,MYF(0));
  }

  FIX: we remove load_defaults from parse_args and call it
  before. Then we save argv with defaults in defaults_argv BEFORE
  calling parse_args (which inside can then call handle_options
  at will). Actually, found out that this is in fact kind of a
  backport for BUG#38468 into 5.1, so I merged in the test case
  as well and added error check for load_defaults call.

  Fix based on:
  revid:zhenxing.he@sun.com-20091002081840-uv26f0flw4uvo33y


Issue #3 
--------

  DESCRIPTION: the structure st_print_event_info constructor
  would not initialize the sql_mode member, although it did for
  sql_mode_inited (set to false). This would later raise the
  warning in valgrind when printing the sql_mode in the event
  header, as this print out is protected by a check against
  sql_mode_inited and sql_mode variables. Given that sql_mode was
  not initialized valgrind would output the warning.

  FIX: we add initialization of sql_mode to the
  st_print_event_info constructor.
 

client/mysqlbinlog.cc:
  - Conditionally free ev->temp_buf.
  - save defaults_argv before handle_options is called.
mysql-test/t/mysqlbinlog.test:
  Added test case from BUG#38468.
sql/log_event.cc:
  Added initialization of sql_mode for st_print_event_info.

Fixed a compilation warning.

This bug is just one facet of stored routines not being able to
detect changes in meta-data (WL#4179). This particular problem
can be triggered within a single session due to the improper
management of the pre-locking list if the view is expanded after
the pre-locking list is calculated.

Since the overall solution for the meta-data detection issue is
planned for a later release, for now a workaround is used to
fix this particular aspect that only involves a single session.
The workaround is to flush the thread-local stored routine cache
every time a view is created or modified, causing locally cached
routines to be re-evaluated upon invocation.

mysql-test/r/sp-bugs.result:
  Add test case result for Bug#50624.
mysql-test/t/sp-bugs.test:
  Add test case for Bug#50624.
sql/sp_cache.cc:
  Update function description.
sql/sql_view.cc:
  Invalidate the SP cache if a view is being created or modified.

The problem was that a DROP TRIGGER statement inside a stored
procedure could cause a crash in subsequent invocations. This
was due to the addition, on the first execution, of a temporary
table reference to the stored procedure query table list. In
a subsequent invocation, there would be a attempt to reinitialize
the temporary table reference, which by then was already gone.

The solution is to backup and reset the query table list each
time a trigger needs to be dropped. This ensures that any temp
changes to the query table list are discarded. It is safe to
do so at this time as drop trigger is restricted from more
complicated scenarios (ie, not allowed within stored functions,
etc).

mysql-test/r/sp-bugs.result:
  Add test case result for Bug#50423
mysql-test/t/sp-bugs.test:
  Add test case for Bug#50423
sql/sql_trigger.cc:
  Backup and reset the query table list.
  Remove now unnecessary manual reset of the query table list.

Server crashes when accessing ARCHIVE table with missing
.ARZ file.

When opening a table, ARCHIVE didn't properly pass through
error code from lower level azopen() to higher level open()
method.

mysql-test/r/archive.result:
  A test case for BUG#48757.
mysql-test/t/archive.test:
  A test case for BUG#48757.
storage/archive/ha_archive.cc:
  Pass through error code from azopen().

Bulk REPLACE or bulk INSERT ... ON DUPLICATE KEY UPDATE may
break dynamic record MyISAM table.

The problem is limited to bulk REPLACE and INSERT ... ON
DUPLICATE KEY UPDATE, because only these operations may
be done via UPDATE internally and may request write cache.

When flushing write cache, MyISAM may write remaining
cached data at wrong position. Fixed by requesting write
cache to seek to a correct position.

mysql-test/r/myisam.result:
  A test case for BUG#49628.
mysql-test/t/myisam.test:
  A test case for BUG#49628.
storage/myisam/mi_dynrec.c:
  delete_dynamic_record() may change data file position.
  IO cache must be notified as it may still have cached
  data, which has to be flushed later.

            table and view...

Invalid memory reads after a query referencing MyISAM table
multiple times with write lock. Invalid memory reads may
lead to server crash, valgrind warnings, incorrect values
in INFORMATION_SCHEMA.TABLES.{TABLE_ROWS, DATA_LENGTH,
INDEX_LENGTH, ...}.

This may happen when one of the table instances gets closed
after a query, e.g. out of slots in open tables cache. UNION,
MERGE and VIEW are irrelevant.

The problem was that MyISAM didn't restore state info
pointer to default value.

myisam/mi_locking.c:
  When a query is referencing MyISAM table multiple times
  with a write lock, all table instances share the same
  state info, pointing to MI_INFO::save_state of
  "primary" table instance.
  
  When lock is released, state pointer was restored only
  for the primary table instance. Secondary table instances
  are still pointing to save_state of primary table
  instance.
  
  Primary table instance may get closed, leaving secondary
  table instances state pointer pointing to freed memory.
  
  That's mostly ok, since next lock will update state info
  pointer to correct value. But there're some cases, when
  this secondary table instance state info is accessed
  without a lock, e.g. INFORMATION_SCHEMA, MERGE (in 5.1
  and up), MyISAM itself for DBUG purposes.
  
  Restore default value of state pointer unconditionally,
  for both primary and secondary table instances.
mysql-test/r/myisam.result:
  A test case for BUG#48438.
mysql-test/t/myisam.test:
  A test case for BUG#48438.

In case of 'CREATE VIEW' subselect transformation does not happen(see JOIN::prepare).
During fix_fields Item_row may call is_null() method for its arugmens which
leads to item calculation(wrong subselect in our case as
transformation did not happen before). This is_null() call
does not make sence for 'CREATE VIEW'.
Note:
Only Item_row is affected because other items don't call is_null() 
during fix_fields() for arguments.

mysql-test/r/view.result:
  test case
mysql-test/t/view.test:
  test case
sql/item_row.cc:
  skip is_null() call in case of 'CREATE VIEW' as unnecessary.

related bits.

this includes a major whitespace (formatting) alignment
and sequence changes to better agree with other spec files.

Further changes:
- All features are controlled by "%define" set from call
  options or builtin.
- "bundled zlib" is on by default.
- "with libgcc" is controlled by runtime detection of gcc.
- Handling of "CFLAGS" and "CXXFLAGS" is more concentrated.
- Several missing man pages were added.

  when converting to a enumerated type.

SHOW CREATE TABLE on a view (v1) that contains a function whose
statement uses another view (v2), could trigger a infinite loop
if the view referenced within the function causes a warning to
be raised while opening the said view (v2).

The problem was a infinite loop over the stack of internal error
handlers. The problem would be triggered if the stack contained
two or more handlers and the first two handlers didn't handle the
raised condition. In this case, the loop variable would always
point to the second handler in the stack.

The solution is to correct the loop variable assignment so that
the loop is able to iterate over all handlers in the stack.

mysql-test/r/view.result:
  Add test case result for Bug#48449.
mysql-test/std_data/bug48449.frm:
  Add a incomplete view definition that causes a warning to be
  issued.
mysql-test/t/view.test:
  Add test case for Bug#48449
sql/sql_class.cc:
  Iterate over all handlers in the stack.

logging is disabled

Post-push fix: disabling test when running mysqld in 
               embedded mode.

Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).

There are two related problems:

1) The query like this:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa

returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.

The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.

Fix: if
       a) we grouping by a subquery and
       b) that subquery has outer references to FROM list
          of the grouping query,
     then we substitute these outer references with
     Item_direct_ref like references under aggregate
     functions: Item_direct_ref obtains data directly
     from the current record.

2) The query with a non-trivial grouping expression like:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa+0

also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().

Fix: include aliased items into GROUP BY item tree instead
     of Item_ref references to them.



mysql-test/r/group_by.result:
  Test case for bug #45640
mysql-test/t/group_by.test:
  Test case for bug #45640
sql/item.cc:
  Bug #45640: optimizer bug produces wrong results
  
  Item_field::fix_fields() has been modified to resolve
  aliases in GROUP BY item trees into aliased items instead
  of Item_ref items.
sql/item.h:
  Bug #45640: optimizer bug produces wrong results
  
  - Item::find_item_processor() has been introduced.
  - Item_ref::walk() has been modified to apply processors
    to itself too (not only to referenced item).
sql/mysql_priv.h:
  Bug #45640: optimizer bug produces wrong results
  
  fix_inner_refs() has been modified to accept group_list
  parameter.
sql/sql_lex.cc:
  Bug #45640: optimizer bug produces wrong results
  
  Initialization of st_select_lex::group_fix_field has
  been added.
sql/sql_lex.h:
  Bug #45640: optimizer bug produces wrong results
  
  The st_select_lex::group_fix_field field has been introduced
  to control alias resolution in Itef_fied::fix_fields.
sql/sql_select.cc:
  Bug #45640: optimizer bug produces wrong results
  
  - The fix_inner_refs function has been modified to treat
    subquery outer references like outer fields under aggregate
    functions, if they are included in GROUP BY item tree.
  
  - The find_order_in_list function has been modified to
    fix Item_field alias fields included in the GROUP BY item
    trees in a special manner.

logging is disabled
      
The server would hit an assertion because of a DBUG violation.
There was a missing DBUG_RETURN and instead a plain return
was used.
      
This patch replaces the return with DBUG_RETURN.

into slow log
      
While processing a statement, down the mysql_parse execution
stack, the thd->enable_slow_log can be assigned to
opt_log_slow_admin_statements, depending whether one is executing
administrative statements, such as ALTER TABLE, OPTIMIZE,
ANALYZE, etc, or not. This can have an impact on slow logging for
statements that are executed after an administrative statement
execution is completed.
      
When executing statements directly from the user this is fine
because, the thd->enable_slow_log is reset right at the beginning
of the dispatch_command function, ie, everytime a new statement
is set is set to execute.
      
On the other hand, for slave SQL thread (sql_thd) the story is a
bit different. When in SBR the sql_thd applies statements by
calling mysql_parse. Right after, it calls log_slow_statement
function to log them if they take too long. Calling mysql_parse
directly is fine, but also means that dispatch_command function
is bypassed. As a consequence, thd->enable_slow_log does not get
a chance to be reset before the next statement to be executed by
the sql_thd. If the statement just executed by the sql_thd was an
administrative statement and logging of admin statements was
disabled, this means that sql_thd->enable_slow_log will be set to
0 (disabled) from that moment on. End result: sql_thd stops
logging slow statements.
      
We fix this by resetting the value of sql_thd->enable_slow_log to
the value of opt_log_slow_slave_statements right after
log_slow_stement is called by the sql_thd.

To 5.x Release
      
Notes
=====
      
This is a backport of BUG#23300 into 5.1 GA.
      
Original cset revid (in betony):
luis.soares@sun.com-20090929140901-s4kjtl3iiyy4ls2h

Description
===========
      
When using replication, the slave will not log any slow query
logs queries replicated from the master, even if the
option "--log-slow-slave-statements" is set and these take more
than "log_query_time" to execute.
                    
In order to log slow queries in replicated thread one needs to
set the --log-slow-slave-statements, so that the SQL thread is
initialized with the correct switch. Although setting this flag
correctly configures the slave thread option to log slow queries,
there is an issue with the condition that is used to check
whether to log the slow query or not. When replaying binlog
events the statement contains the SET TIMESTAMP clause which will
force the slow logging condition check to fail. Consequently, the
slow query logging will not take place.
                    
This patch addresses this issue by removing the second condition
from the log_slow_statements as it prevents slow queries to be
binlogged and seems to be deprecated.

Get rid of trailing blanks.

Cleanup, formatting improvements,
vendor is Sun (since MySQL AB was bought).

Backport the change so that RPM doesn't magically
create a dependency on "Perl-DBI".

Fixed 2 problems :
1. test_if_order_by_key() was continuing on the primary key
as if it has a primary key suffix (as the secondary keys do).
This leads to crashes in ORDER BY <pk>,<pk>.
Fixed by not treating the primary key as the secondary one
and not depending on it being clustered with a primary key.
2. The cost calculation was trying to read the records 
per key when operating on ORDER BYs that order on all of the 
secondary key + some of the primary key.
This leads to crashes because of out-of-bounds array access.
Fixed by assuming we'll find 1 record per key in such cases.

The problem was that the dbug facility was being used after the
per-thread dbug state had already been finalized. The was present
in a few functions which invoked decrement_handler_count, which
in turn invokes my_thread_end on Windows. In my_thread_end, the
per-thread dbug state is finalized. Any use after the state is
finalized ends up creating a new state.

The solution is to process the exit of a function before the
decrement_handler_count function is called.


sql/mysqld.cc:
  Process the function exit before decrement_handler_count is
  called, as it can end the per-thread dbug state on Windows.

Updated the certs to expire on 2015. 
Made sure they work with both yassl and openssl.

column is used for ORDER BY

Problem: filesort isn't meant for null length sort data
(e.g. char(0)), that leads to a server crash.

Fix: disregard sort order if sort data record length is 0 (nothing
to sort).


mysql-test/r/select.result:
  Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
  column is used for ORDER BY
    - test result.
mysql-test/t/select.test:
  Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
  column is used for ORDER BY
    - test case.
sql/filesort.cc:
  Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
  column is used for ORDER BY
    - assert added as filesort cannot handle null length sort data.
sql/sql_select.cc:
  Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
  column is used for ORDER BY
    - don't sort null length data e.g. in case of ORDER BY CHAR(0).

  Define env. vars for both timeout settings
  This patch is for 5.0 (mtr v1) and should replaces for 5.1 up

The problem was that a failure to open a view wasn't being
properly handled. When opening a view with unknown definer,
the open procedure would be treated as successful and would
later crash when attempting to lock the view (which wasn't
opened to begin with).

The solution is to skip further processing when opening a
table if it fails with a fatal error.

mysql-test/r/view.result:
  Add test case result for Bug#47734.
mysql-test/t/view.test:
  Add test case for Bug#47734.
sql/sql_base.cc:
  Skip further processing if opening a table failed due to
  a fatal error (for the statement).

being logged to slow query log

The problem is that the execution time for a multi-statement
stored procedure as a whole may not be accurate, and thus not
be entered into the slow query log even if the total time
exceeds long_query_time. The reason for this is that
THD::utime_after_lock used for time calculation may be reset
at the start of each new statement, possibly leaving the total
SP execution equal to the time spent executing the last
statement in the SP.

This patch stores the utime on start of SP execution, and
restores it on exit of SP execution. A test is added.


mysql-test/suite/sys_vars/r/slow_query_log_func.result:
  New test results for #47905.
mysql-test/suite/sys_vars/t/slow_query_log_func.test:
  New test case for #47905.
sql/sp_head.cc:
  Save and restore the THD::utime_after_lock on entry and 
  exit of execute_procedure().

The problem becomes apparent only if HAVE_purify is undefined.
It related to the part of code placed in open_table_from_share() fuction
where we initialize record buffer only if HAVE_purify is enabled.
So in case of HAVE_purify=OFF record buffer is not initialized
on open table stage.
Next we read key, find NULL value and update appropriate null bit
but do not update record buffer. After that the record is stored
in the join cache(store_record_in_cache). For CHAR fields we
strip trailing spaces and in our case this procedure uses
uninitialized record buffer.
The fix is to skip stripping space procedure in case of null values
for CHAR fields(partially based on 6.0 JOIN_CACHE implementation).


mysql-test/r/join.result:
  test case
mysql-test/t/join.test:
  test case
sql/field.cc:
  code updated according to new CACHE_FIELD struct
sql/sql_select.cc:
  code updated according to new CACHE_FIELD struct
sql/sql_select.h:
  CACHE_FIELD struct:
  added new fields: Field *field, uint type;
  removed fields: Field_blob *blob_field, bool strip;

error causes debug assertion

The IGNORE option of the multiple-table UPDATE command was
not intended to suppress errors caused by the
sql_safe_updates mode. This flag will raise an error if the
execution of UPDATE does not use a key for row retrieval,
and should continue do so regardless of the IGNORE option.

However the implementation of IGNORE does not support
exceptions to the rule; it always converts errors to
warnings and cannot be extended. The Internal_error_handler
interface offers the infrastructure to handle individual
errors, making sure that the error raised by
sql_safe_updates is not silenced.

Fixed by implementing an Internal_error_handler and using it
for UPDATE IGNORE commands.