Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5395

Fix a bug in the read lock implementation when there is a lot of contention

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: WT3.2.2, 4.3.3, 4.2.4, 4.0.17
    • Component/s: None
    • Labels:
    • Story Points:
      8
    • Sprint:
      Storage Engines 2020-01-27
    • Backport Requested:
      v4.2, v4.0

      Description

      While running Workgen benchmark evict-btree-lookaside.py with a higher number of reader/search threads, we hit an assert in __wt_readlock() with following message:

       

      WT_CURSOR.search: __wt_readlock, 274: ticket == l->u.s.current && l->u.s.readers_active > 0
      WT_CURSOR.search: __wt_abort, 28: aborting WiredTiger library
      

       

      Summary:

      Read/write lock implementation in WiredTiger has a bug where a call for read lock through _wt_readlock() would result in assert. This only happens when there are a large number of readers and writers threads that are competing for the lock. This root cause is a buggy piece of code in implementation of wt_readlock() that results in variable value to overflow beyond the maximum value. This bug has existed since current R/W lock was implemented through WT-3345.  

        Attachments

          Activity

            People

            Assignee:
            haseeb.bokhari Haseeb Bokhari
            Reporter:
            haseeb.bokhari Haseeb Bokhari
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: