Opened 4 years ago

Closed 4 years ago

#10651 closed Support Requests (wontfix)

boost::thread leaks memory when using the MinGW compiler

Reported by: michael.burr@… Owned by: Niall Douglas
Milestone: To Be Determined Component: thread
Version: Boost 1.56.0 Severity: Problem
Keywords: Cc:

Description

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.

Change History (11)

comment:1 Changed 4 years ago by viboes

Owner: changed from Anthony Williams to viboes
Status: newassigned

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by viboes

Owner: changed from viboes to Niall Douglas
Status: assignednew

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?

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by 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

comment:6 Changed 4 years ago by viboes

Niall, have you take a look at the intrusive_ptr?

comment:7 Changed 4 years ago by 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

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by viboes

Any news on this issue?

comment:10 Changed 4 years ago by viboes

Type: BugsSupport Requests

Moved to support, until there is more feedback.

comment:11 Changed 4 years ago by viboes

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.