Boost C++ Libraries: Ticket #10651: boost::thread leaks memory when using the MinGW compiler

owner, status changed

viboes — Sun, 12 Oct 2014 09:38:05 GMT

owner changed from Anthony Williams to viboes
status new → assigned

viboes — Sun, 12 Oct 2014 09:47:49 GMT

Does the program behaves the same if you define BOOST_THREAD_PROVIDES_THREAD_DESTRUCTOR_CALLS_TERMINATE_IF_JOINABLE?

You could also define BOOST_THREAD_VERSION = 4.

owner, status changed

viboes — Sun, 12 Oct 2014 10:00:17 GMT

owner changed from viboes to Niall Douglas
status assigned → new

There is a line in boost/thread/win32/thread_data.hpp that is suspect

        typedef boost::intrusive_ptr<detail::thread_data_base> thread_data_ptr;

I have no access to a windows platform. Could you try replacing intrusive_ptr by shared_ptr?

Niall, please could you try to reproduce and try this patch?

michael.burr@… — Mon, 13 Oct 2014 03:29:45 GMT

I added the lines

#define BOOST_THREAD_PROVIDES_THREAD_DESTRUCTOR_CALLS_TERMINATE_IF_JOINABLE 1
#define BOOST_THREAD_VERSION 4

to boost/config/user.hpp and rebuilt the library. This didn't have an effect on the problem.

But to be honest, I'm not 100% sure this is the right way to do what you asked.

I have also tried changing the typedef for thread_data_ptr to:

typedef boost::shared_ptr<detail::thread_data_base> thread_data_ptr;

but that results in several other compiler errors occurring. I haven't had a chance to work through updaing the uses of thread_data_ptr to resolve those errors.

Niall Douglas — Mon, 13 Oct 2014 09:29:17 GMT

I wouldn't be surprised if this leak in Mingw is simply accepted as is. Boost.Thread hooks itself into the PE process state change function pointer table by quite literally marking the memory pages as writable and overwriting the relevant entries. The logic which tracks down where to write is somewhat brittle, and almost certainly made the assumption that MSVCRT is the CRT.

VS14 ships a whole new MSVCRT thank god, so it may be the same leak may manifest there too as the heuristics may simply be out of date.

Can the OP try Mingw-w64 (this being the much improved rewrite of Mingw) first? Mingw32 is currently not compiling with Boost 1.56 by the way, that's a mea culpa but Mingw-w64 works fine. Mingw32 is also frequently subtly broken, whereas Mingw-w64 tends to have much superior QA e.g. right now Mingw32 fails to enumerate directories reliably.

Niall

viboes — Sat, 25 Oct 2014 15:26:38 GMT

Niall, have you take a look at the intrusive_ptr?

Niall Douglas — Sun, 26 Oct 2014 17:11:18 GMT

Not yet. Last weekend and this one my wife was away so I have been baby minding. And the baby dislikes me looking after her, so I am too tired to think in code. This coming weekend should be back to normal i.e. I get my Saturday back. I am aware of the 1.57 deadline. N

Niall Douglas — Sat, 01 Nov 2014 16:01:53 GMT

I ran this test case on Boost 1.57 beta 1 on Mingw with GCC 4.8.1 32 bit on Win8.1 x86 both debug and release builds. I see no leak of memory, it's flat as a pancake at 0.4Mb. Overall system memory does not increase either. I left it run for 10 minutes each build where it drew down about 70% CPU, still no change in RAM consumption.

It could be my system is a dual core CPU? If this is a timing related leak it may be unreproducible on my machine? Or else the bug has been fixed, or most likely of all this is yet another bug in Mingw which has poor QA.

OP: Can you try Mingw-w64 please and see if it replicates there on your hardware? If it does, it's a bug in Boost, if it doesn't it's a bug in Mingw.

viboes — Sat, 06 Dec 2014 09:55:56 GMT

Any news on this issue?

type changed

viboes — Sat, 13 Dec 2014 16:08:06 GMT

type Bugs → Support Requests

Moved to support, until there is more feedback.

status changed; resolution set

viboes — Sat, 04 Apr 2015 21:43:43 GMT

status new → closed
resolution → wontfix

We need tome tester help in order to be able to fix it. Closed until we get it.