LOCK_thd_data and MYSQL_CALLBACK

Bug #1242748 reported by Raghavendra D Prabhu on 2013-10-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Undecided
Unassigned
5.6
High
Sergei Glushchenko

Bug Description

In 5.6 PS code, mysqld.cc:

    mysql_mutex_lock(&tmp->LOCK_thd_data);
    MYSQL_CALLBACK(thread_scheduler, post_kill_notification, (tmp));

However, in mysql-56, mysql-55 and PS-55, the order is

    MYSQL_CALLBACK(thread_scheduler, post_kill_notification, (tmp));
    mysql_mutex_lock(&tmp->LOCK_thd_data);

So, the order of locking is reversed there (though it may/not
matter depending on what is done in post_kill_notification).

This needs to be resolved in either 5.6 PS or 5.5 PS.

Related branches

lp:~sergei.glushchenko/percona-server/5.6-ps-bug1242748
Merged into lp:percona-server at revision 485
Laurynas Biveinis: Approve on 2013-10-23

This changed in 5.6 because 5.6 has different behavior on THD destroy which causes to memory corruption when thread released without LOCK_thd_data locked. On 5.5 it is not necessary. See https://mariadb.atlassian.net/browse/MDEV-4889 for details.

Changed in percona-server:
status: New → Invalid

Thanks for details.

However, down a few lines, another set of calls were added recently in

476 revid:<email address hidden> for dump threads which has following:

        MYSQL_CALLBACK(thread_scheduler, post_kill_notification, (tmp));
        mysql_mutex_lock(&tmp->LOCK_thd_data);

Should this also be fixed?

Indeed, rev 0.18888.88 (upstream merge) added one more loop to kill threads with post_kill_notification not protected by LOCK_thd_data, which is the bug for PS due to thread pool.

Thanks to Raghavendra D Prabhu for good catch!

tags: added: merge-regression
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers