script/thread-sanitizer.supp

   1 # In attr_file_free, the locks are acquired in the opposite order in which they
   2 # are normally acquired. This is probably something worth fixing to have a
   3 # consistent lock hierarchy that is easy to understand.
   4 deadlock:attr_cache_lock
   5
   6 # git_mwindow_file_register has the possibility of evicting some files from the
   7 # global cache. In order to avoid races and closing files that are currently
   8 # being accessed, before evicting any file it will attempt to acquire that
   9 # file's lock. Finally, git_mwindow_file_register is typically called with a
  10 # file lock held, because the caller will use the fd in the mwf immediately
  11 # after registering it. This causes ThreadSanitizer to observe different orders
  12 # of acquisition of the mutex (which implies a possibility of a deadlock),
  13 # _but_ since the files are added to the cache after other files have been
  14 # evicted, there cannot be a case where mwf A is trying to be registered while
  15 # evicting mwf B concurrently and viceversa: at most one of them can be present
  16 # in the cache.
  17 deadlock:git_mwindow_file_register
  18
  19 # When invoking the time/timezone functions from git_signature_now(), they
  20 # access libc methods that need to be instrumented to correctly analyze the
  21 # data races.
  22 called_from_lib:libc.so.6
  23
  24 # TODO(#5592): Investigate and fix this. It can be triggered by the `thread`
  25 # test suite.
  26 race:git_filter_list__load_ext