[Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used

[Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used

[pg.ensiie at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857

            Bug ID: 107857
           Summary: recursive_mutex misses destructor if non-function call
                    initialization is used
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pg.ensiie at gmail dot com
  Target Milestone: ---

Hello,

Using GCC 11.2.0 with mingw-w64 9.0.0.

I notice that there is a memory leak when using a std::recursive_mutex, as
described in this issue : https://sourceforge.net/p/mingw-w64/bugs/851/. I
reproduce this bug.

After some research, I discover that same problem has occured for std::mutex,
that was solved by this fix : https://sourceforge.net/p/mingw-w64/bugs/851/

The solution is to use function initialized and destructor for recursive_mutex
as it is done for mutex when using pthread on windows. Defining
_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC in os_defines.h fixes the bug.

Even if I do not use it, I wonder if _GTHREAD_USE_COND_INIT_FUNC should also be
set for condition variables.

[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Could you please run this and paste the output here?

#include <mutex>
#include <shared_mutex>
#include <condition_variable>
#include <iostream>
#include <processthreadsapi.h>

unsigned long
muh_handles()
{
    unsigned long n = 0;
    if (GetProcessHandleCount(GetCurrentProcess(), &n))
      return n;
    throw;
}

int main()
{
  int start, end;

  start = muh_handles();
  {
    std::mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::mutex: " << (end - start) << std::endl;

  start = end;
  {
    std::recursive_mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::recursive_mutex: " << (end - start) <<
std::endl;

  start = end;
  {
    std::timed_mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::timed_mutex: " << (end - start) <<
std::endl;

  start = end;
  {
    std::recursive_timed_mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::recursive_timed_mutex: " << (end -
start) << std::endl;

  start = end;
  {
    std::shared_mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::shared_mutex: " << (end - start) <<
std::endl;

  start = end;
  {
    std::shared_timed_mutex m;
    m.lock();
    m.unlock();
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::shared_timed_mutex: " << (end - start)
<< std::endl;

  start = end;
  {
    std::mutex m;
    std::unique_lock<std::mutex> l(m);
    std::condition_variable cv;
    cv.wait_for(l, std::chrono::seconds(0));
  }
  end = muh_handles();
  std::cout << "Handles leaked by std::condition_variable: " << (end - start)
<< std::endl;
}

I tried to check it on Wine, but the Windows function isn't implemented:
012c:fixme:process:NtQueryInformationProcess ProcessHandleCount
(0xffffffffffffffff,0x7ffffe2ffdfc,0x00000004,(nil)) stub

[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See also https://stackoverflow.com/a/77515095/981959

[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> See also https://stackoverflow.com/a/77515095/981959

And my comment there:

This seems like a bug in winpthreads. The INITIALIZER macro should not exist if
destroying the mutex requires a function call. Either you need a function call
to create it and destroy it, or you use the initializer macro and don't need to
do anything to destroy it.