[Bug libstdc++/59807] 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=59807

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
If the target for this is only mingw-w64 then PR 57440 is a dup

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

[ktietz at gcc dot gnu.org]

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

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org ---
Agreed, this bug is duplicate of PR/57440

*** This bug has been marked as a duplicate of bug 57440 ***

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

[ahanins at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #4 from Andrey H. ahanins at gmail dot com ---
Thanks Jonathan, I followed your suggestion regarding os_defines.h, recompiled
the whole mingw-w64 toolchain and can confirm that it helps. But doesn't it
meant that it should be fixed in GCC sources itself (I mean in
libstdc++-v3/config/os/mingw32-w64/os_defines.h). Or there is other standard
way how to influence os_defines.h during configuration phase?

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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, the copy in the sources needs to be fixed.  Does mingw-w64 always use
winpthread?

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

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-29
 Ever confirmed|0   |1

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #5)
 Yes, the copy in the sources needs to be fixed.  Does mingw-w64 always use
 winpthread?

Sadly, no.  The use of POSIX-threading is optional.  That was actual the reason
why I didn't added it by default.  We would need to probe if pthread-library is
present, and just then activate enable it.

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

[ahanins at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #7 from Andrey H. ahanins at gmail dot com ---
Kai, so what would be the fix?
IMHO, this bug is quite a show stopper for C++11 threading in Mingw-w64, so
maybe it worth to create a temporary patch for Mingw-w64 compilation with
pthreads support just to have a working toolchain?

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

[ahanins at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #1 from Andrey H. ahanins at gmail dot com ---
Simplest code which leaks handles on Windows:

for(;;) {
  std::mutex op_mutex;
  op_mutex.lock();
  op_mutex.unlock();
}

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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
It a target's pthread_mutex requires cleanup then it should not define
__GTHREAD_MUTEX_INIT, it should use the init function, and then it gets a
chance to also run a destroy function.

That can be controlled by defining _GTHREAD_USE_MUTEX_INIT_FUNC in the relevant
libstdc++-v3/config/os/xxx/os_defines.h header.

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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
In other words, we already have all the machinery in place to handle such
cases, it just needs to be used for the target.