Percona Server with XtraDB

LOCK_thd_data and MYSQL_CALLBACK

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.

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