1. 13 Dec, 2019 1 commit
    • refs: rename git_reference__set_name to git_reference__realloc · 97b8491b
      As git_reference__name will reallocate storage to account for longer
      names (it's actually allocator-dependent), it will cause all existing
      pointers to the old object to become dangling, as they now point to
      freed memory.
      
      Fix the issue by renaming to a more descriptive name, and pass a pointer
      to the actual reference that can safely be invalidated if the realloc
      succeeds.
      Etienne Samson committed
  2. 07 Dec, 2019 1 commit
  3. 04 Dec, 2019 3 commits
  4. 03 Dec, 2019 3 commits
  5. 01 Dec, 2019 3 commits
  6. 29 Nov, 2019 2 commits
    • global: convert to fiber-local storage to fix exit races · 5c6180b5
      On Windows platforms, we automatically clean up the thread-local storage
      upon detaching a thread via `DllMain()`. The thing is that this happens
      for every thread of applications that link against the libgit2 DLL, even
      those that don't have anything to do with libgit2 itself. As a result,
      we cannot assume that these unsuspecting threads make use of our
      `git_libgit2_init()` and `git_libgit2_shutdow()` reference counting,
      which may lead to racy situations:
      
          Thread 1                    Thread 2
      
          git_libgit2_shutdown()
                                      DllMain(DETACH_THREAD)
                                      git__free_tls_data()
          git_atomic_dec() == 0
          git__free_tls_data()
          TlsFree(_tls_index)
                                      TlsGetValue(_tls_index)
      
      Due to the second thread never having executed `git_libgit2_init()`, the
      first thread will clean up TLS data and as a result also free the
      `_tls_index` variable. When detaching the second thread, we
      unconditionally access the now-free'd `_tls_index` variable, which is
      obviously not going to work out well.
      
      Fix the issue by converting the code to use fiber-local storage instead
      of thread-local storage. While FLS will behave the exact same as TLS if
      no fibers are in use, it does allow us to specify a destructor similar
      to the one that is accepted by pthread_key_create(3P). Like this, we do
      not have to manually free indices anymore, but will let the FLS handle
      calling the destructor. This allows us to get rid of `DllMain()`
      completely, as we only used it to keep track of when threads were
      exiting and results in an overall simplification of TLS cleanup.
      Patrick Steinhardt committed
  7. 28 Nov, 2019 16 commits
  8. 27 Nov, 2019 4 commits
  9. 25 Nov, 2019 5 commits
  10. 24 Nov, 2019 2 commits