Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10010

Recursive call to mysql_rwlock_rdlock for LOCK_system_variables_hash

Details

    • 10.1.15

    Description

      Application verifier reports an error in plugins_var test (recursive read lock on reader writer lock) for LOCK_system_variables_hash.

      The lock is acquired in sql_show.cc , in fill_variables() function

       mysql_rwlock_rdlock(&LOCK_system_variables_hash);
        res= show_status_array(thd, wild, enumerate_sys_vars(thd, sorted_vars, scope),
                               scope, NULL, "", tables->table,
                               upper_case_names, partial_cond);
        mysql_rwlock_unlock(&LOCK_system_variables_hash);
      

      however the same lock is acquired again deeper inside show_status array. appverifier points to this callstack

      srw_rdlock+0xa [h:\work\server\mysys\thr_rwlock.c @ 89]
      intern_sys_var_ptr+0x9b [h:\work\server\sql\sql_plugin.cc @ 2981]
      sys_var_pluginvar::do_value_ptr+0x15 [h:\work\server\sql\sql_plugin.cc @ 3405]
      sys_var::value_ptr+0x42 [h:\work\server\sql\set_var.cc @ 254]
      show_status_array+0x33e [h:\work\server\sql\sql_show.cc @ 3285]
      fill_variables+0x148 [h:\work\server\sql\sql_show.cc @ 7197]
      

      On Windows, recursive shared lock acquire can cause a deadlock. Here is the explanation of the bug given by windbg command '!analyze -v'
      APPLICATION_VERIFIER_SRWLOCK_RECURSIVE_ACQUIRE (253)
      The SRW lock is being acquired recursively by the same thread.
      This stop is generated if the SRW lock (Param1) is being acquired
      recursively by the same thread.
      This will result in a deadlock and the thread would block indefinitely.
      Recursive acquisition of an SRW lock in exclusive mode will cause a deadlock.
      Recursive acquisition of an SRW lock in shared mode will cause a deadlock when
      there is a thread waiting for exclusive access. Consider the example below:

      • Thread A acquires the SRW lock in shared mode
      • Thread B tries to acruire the SRW lock in exclusive mode and waits
      • Thread A tries to acquire the SRW lock in shared mode recursively. This will
        be successful as long as there is no exclusive waiter (in this case B). Since
        SRW locks do not have writer starvation, thread A waits behind thread B.
        Now, Thread B is waiting for Thread A which is inturn waiting for Thread B
        causing a circular wait and hence a deadlock.

      Attachments

        Activity

          svoj Sergey Vojtovich added a comment - See also https://jira.mariadb.org/browse/MDEV-5089?focusedCommentId=41621&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-41621 I agree it should be fixed, but it's not that trivial.

          Thanks for the above link. It points to single unix spec But
          http://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html which I did not read prior, which says recursive rdlock must be possible. This is not exactly how Windows does it. If anything else fails, we could make Windows compliant to the spec, at the expense of introducing an atomic counter for readers

          wlad Vladislav Vaintroub added a comment - Thanks for the above link. It points to single unix spec But http://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html which I did not read prior, which says recursive rdlock must be possible. This is not exactly how Windows does it. If anything else fails, we could make Windows compliant to the spec, at the expense of introducing an atomic counter for readers

          Thinking a little more, it may not be as easy to add recursion to SRW locks.... The last measure of going back to generic implementation with in thr_rwlock with mutex and condition variable, but maybe we can avoid it for this single case of read lock recursion.

          wlad Vladislav Vaintroub added a comment - Thinking a little more, it may not be as easy to add recursion to SRW locks.... The last measure of going back to generic implementation with in thr_rwlock with mutex and condition variable, but maybe we can avoid it for this single case of read lock recursion.

          On why windows reader-writer lock can't be used recursively see also https://blogs.msdn.microsoft.com/oldnewthing/20160506-00/?p=93416

          wlad Vladislav Vaintroub added a comment - On why windows reader-writer lock can't be used recursively see also https://blogs.msdn.microsoft.com/oldnewthing/20160506-00/?p=93416

          serg, please review fix for this bug.
          wlad, do you think this patch will make Application Verifier happy?

          svoj Sergey Vojtovich added a comment - serg , please review fix for this bug. wlad , do you think this patch will make Application Verifier happy?

          elenst , I backported the fix to 5.5

          wlad Vladislav Vaintroub added a comment - elenst , I backported the fix to 5.5

          People

            svoj Sergey Vojtovich
            wlad Vladislav Vaintroub
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.