boost::thread leaks memory when using the MinGW compiler

[michael.burr@…]

boost::thread leaks memory when using the MinGW compiler

This report is based on information originally from:

[hxxp://stackoverflow.com/questions/26284056/threads-hogging-up-memory]

When the following program is compiled with MinGW, the memory use of the process continually increases:

#include <boost/thread.hpp>

void thread_func()
{
    return;
}

int main()
{
    for (;;) {
        boost::thread t1(thread_func);
        boost::thread t2(thread_func);

        t1.join();
        t2.join();
    }
}

Any one of the following changes to the program seem to make the memory leak go away:

• add a call to the Windows API Sleep(1) to thread_func()
• use only a single thread
• move the call to t1.join() to before the creation of t2

I'm not sure if this problem is sensitive to the version of MinGW. I used MinGW 4.8.1 from tdm-gcc:

[hxxp://tdm-gcc.tdragon.net/]

I built a 32-bit program; I'm not sure if a 64-bit program would behave differently.

The problem doesn't occur when MSVC 12 (Visual Studio 2013) is used.

[viboes]

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.

[viboes]

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@…]

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]

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]

Niall, have you take a look at the intrusive_ptr?

[Niall Douglas]

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]

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]

Any news on this issue?

[viboes]

Moved to support, until there is more feedback.

[viboes]

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