public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used
@ 2022-11-24 9:41 pg.ensiie at gmail dot com
2023-12-15 12:17 ` [Bug libstdc++/107857] " redi at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: pg.ensiie at gmail dot com @ 2022-11-24 9:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
2022-11-24 9:41 [Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used pg.ensiie at gmail dot com
@ 2023-12-15 12:17 ` redi at gcc dot gnu.org
2023-12-15 12:31 ` redi at gcc dot gnu.org
2023-12-15 12:32 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-15 12:17 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
2022-11-24 9:41 [Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used pg.ensiie at gmail dot com
2023-12-15 12:17 ` [Bug libstdc++/107857] " redi at gcc dot gnu.org
@ 2023-12-15 12:31 ` redi at gcc dot gnu.org
2023-12-15 12:32 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-15 12:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
2022-11-24 9:41 [Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used pg.ensiie at gmail dot com
2023-12-15 12:17 ` [Bug libstdc++/107857] " redi at gcc dot gnu.org
2023-12-15 12:31 ` redi at gcc dot gnu.org
@ 2023-12-15 12:32 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-12-15 12:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-12-15 12:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-24 9:41 [Bug libstdc++/107857] New: recursive_mutex misses destructor if non-function call initialization is used pg.ensiie at gmail dot com
2023-12-15 12:17 ` [Bug libstdc++/107857] " redi at gcc dot gnu.org
2023-12-15 12:31 ` redi at gcc dot gnu.org
2023-12-15 12:32 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).