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

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Critical - P2
    • WT10.0.0, 4.3.3, 4.2.4, 4.0.17
    • Affects Version/s: None
    • Component/s: None
    • Storage Engines 2020-01-27
    • 8
    • v4.2, v4.0

      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.  

              Assignee:
              Haseeb Bokhari (Inactive)
              Reporter:
              Haseeb Bokhari (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: