Last commit made on 2019-04-17
Get this branch:
git clone -b bb-5.5-sujatha

Branch merges

Branch information


Recent commits

8b066a3... by Sujatha Sivakumar <email address hidden> on 2019-04-17

MDEV-17260: Memory leaks in mysqlbinlog

The mysqlbinlog tool is leaking memory, causing failures in various tests when
compiling and testing with AddressSanitizer or LeakSanitizer like this:

cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_ASAN:BOOL=ON /path/to/source
make -j$(nproc)
cd mysql-test
ASAN_OPTIONS=abort_on_error=1 ./mtr --parallel=auto rpl.rpl_row_mysqlbinlog

CURRENT_TEST: rpl.rpl_row_mysqlbinlog

Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x4eff87 in __interceptor_malloc (/dev/shm/5.5/client/mysqlbinlog+0x4eff87)
#1 0x60eaab in my_malloc /mariadb/5.5/mysys/my_malloc.c:41:10
#2 0x5300dd in Log_event::read_log_event(char const*, unsigned int, char const**,
   Format_description_log_event const*, char) /mariadb/5.5/sql/
#3 0x564a9c in dump_remote_log_entries(st_print_event_info*, char const*)

'mysqlbinlog' tool is being used to read binary log events from a remote server.
While reading binary log, if a fake rotate event is found following actions are

If 'to-last-log' option is specified, then fake rotate event is processed.
In the absence of 'to-last-log' skip the fake rotate event.

In this skipped case the fake rotate event object is not getting cleaned up
resulting in memory leak.

Cleanup the fake rotate event.

This issues is already fixed in MariaDB 10.0.23 and higher versions as part of
commit c3018b0ff4fb02c029787d03867adf0530607bab

370886a... by Vladislav Vaintroub on 2019-04-04

MDEV-17610 Unexpected connection abort after certain operations from within stored procedure

Always set SERVER_MORE_RESULTS_EXIST when executing stored procedure statements

If statements produce a result, EOF packet needs this flag (SP ends
with an OK packet). IF statetement does not produce a result, affected rows
count are part of the final OK packet.

f2d549d... by Sujatha Sivakumar <email address hidden> on 2019-03-27

MDEV-14784: Slave crashes in show_status_array upon running a trigger with
select from I_S

When applier thread tries to access 'variable_name' of
INFORMATION_SCHEMA.SESSION_VARIABLES table through triggers, it results in an
abnormal exit of slave server.

At the time of replication of stored routines and triggers, their associated
security context will be sent by the master. The applier thread on the slave
server will use this information to set the required security context for the
execution of stored routines and triggers. This is achieved as follows.

->The stored routine object has a member named 'm_security_ctx' which holds the
  security context received from master.
->The applier thread's security_ctx is stored into a 'backup' object.

->Set the applier thread's security_ctx to 'm_security_ctx'.

->Upon the completion of stored routine execution restore the original security
  context of applier thread from the backup.

During the above process the 'm_security_ctx' object is not initialized
properly. Hence the 'external_user' of 'm_security_ctx' has invalid value for
this variable and accessing this variable results in abnormal exit of server.

Invoke the Security_context::init() call from the constructor of stored routine
so that 'm_security_ctx' gets initialized properly.

e890711... by Sergey Vojtovich on 2019-03-25

Fixed ps-protocol thread_pool_server_audit failure

By applying 7bd258c.

cfe0fe1... by Bernhard M. Wiedemann on 2019-01-26

Fix tests in 2020

unfortunately, the year 2038 problem prevented me from pushing
the deadline even further into the future.

c61e8a6... by Chris Calender on 2019-03-24

Fix for MDEV-17449, typo in error message (#1146)

d8b7e76... by Chris Calender <email address hidden> on 2019-02-07

Fix for MDEV-18276, typo in error message + all other occurrences of refering

778c525... by Sachin Setiya on 2019-03-20

MDEV-17119 replicate_rewrite_db does not work for single chardatabase name

Fixed issue in logic.

f00e25b... by Chris Calender on 2019-02-10

Fix for MDEV-15538, '-N' Produce html output wrong

0dd12b4... by Igor Babaev on 2019-03-15

MDEV-18896 Crash in convert_join_subqueries_to_semijoins

If an IN-subquery is used in a table-less select the current code
should never consider it as candidate for semi-join optimizations.
Yet the function check_and_do_in_subquery_rewrites() improperly
checked the property "to be a table-less select". As a result
such select in IN subquery was used in INSERT .. SELECT then
the IN subquery by mistake was registered as a semi-join subquery
and convert_subq_to_sj() was called for it. However the code of
this function does not assume that the parent select of the subquery
could be a table-less select.