[threads] Memory leaks in Boost threading support? Version boost_1_53_0
I am running a number of Boost threads communicating via bounded buffers. My programs seem to run properly, but I get a number of memory leaks, usually 4- and 8- byte areas, although a few are longer. As far as I can tell, they are coming from inside Boost, as there is no mention of lines in my code. OTOH, although my code runs fine, it is quite possible that there are subtle errors in it! I am using _CRTDBG_MAP_ALLOC, which is being used correctly as it detected one area of my own that I was not freeing up, and that has been fixed. I am running VC++ 2010 Express on a 64-bit machine. Here is my memory leak display - I tried setting a few of the numbers as breakpoints, using_CrtSetBreakAlloc(), but most of them did not cause breaks. The first one broke at a new in > boost::detail::basic_condition_variable::get_wait_entry() Line 180 + 0x7 bytes C++ Why wouldn't this get freed up?! Note: <bad exception > looks ominous - where is it coming from?! Detected memory leaks! Dumping objects -> {8624} normal block at 0x02312550, 4 bytes long. Data: <HC1 > 48 43 31 02 {8615} normal block at 0x0015F8F8, 4 bytes long. Data: <h!1 > 68 21 31 02 {8602} normal block at 0x023117A0, 4 bytes long. Data: < 51 > F8 35 31 02 {5584} normal block at 0x02311760, 4 bytes long. Data: <@ > 40 F7 15 00 {4013} normal block at 0x0015F948, 4 bytes long. Data: < 1 > 00 17 31 02 {3924} normal block at 0x02314048, 4 bytes long. Data: < <1 > 20 3C 31 02 {3883} normal block at 0x02314008, 4 bytes long. Data: < +1 > D0 2B 31 02 {3862} normal block at 0x02313CA0, 4 bytes long. Data: <h!1 > 68 21 31 02 {445} normal block at 0x02314088, 4 bytes long. Data: < R1 > 88 52 31 02 {440} normal block at 0x023145F8, 4 bytes long. Data: <HC1 > 48 43 31 02 {430} normal block at 0x02314648, 4 bytes long. Data: < 51 > F8 35 31 02 {402} normal block at 0x02313FC0, 4 bytes long. Data: < 1 > 98 1D 31 02 {395} normal block at 0x023136B8, 4 bytes long. Data: < +1 > D0 2B 31 02 {382} normal block at 0x02313A18, 4 bytes long. Data: < 51 > F8 35 31 02 {355} normal block at 0x02312B90, 4 bytes long. Data: <HC1 > 48 43 31 02 {332} normal block at 0x023121E8, 4 bytes long. Data: <h > 68 F8 15 00 {316} normal block at 0x02311978, 4 bytes long. Data: <HC1 > 48 43 31 02 {298} normal block at 0x023117E0, 4 bytes long. Data: < 51 > F8 35 31 02 {270} normal block at 0x023106D0, 4 bytes long. Data: < 1 > E0 0E 31 02 {256} normal block at 0x02310C50, 4 bytes long. Data: < R1 > 88 52 31 02 {225} normal block at 0x0015FC30, 4 bytes long. Data: < > 90 F9 15 00 {217} normal block at 0x0015F5C0, 8 bytes long. Data: <l > 6C F5 15 00 00 00 00 00 {213} normal block at 0x0015E7B8, 8 bytes long. Data: < > 14 E7 15 00 00 00 00 00 {212} normal block at 0x0015E770, 8 bytes long. Data: < > EC E6 15 00 00 00 00 00 {208} normal block at 0x0015D900, 8 bytes long. Data: <\ > 5C D8 15 00 00 00 00 00 {207} normal block at 0x0015D8B8, 8 bytes long. Data: <4 > 34 D8 15 00 00 00 00 00 {203} normal block at 0x0015CA48, 8 bytes long. Data: < > A4 C9 15 00 00 00 00 00 {202} normal block at 0x0015CA00, 8 bytes long. Data: <| > 7C C9 15 00 00 00 00 00 {198} normal block at 0x0015BB90, 8 bytes long. Data: < > EC BA 15 00 00 00 00 00 {197} normal block at 0x0015BB48, 8 bytes long. Data: < > C4 BA 15 00 00 00 00 00 {193} normal block at 0x0015ACD8, 8 bytes long. Data: <4 > 34 AC 15 00 00 00 00 00 {192} normal block at 0x0015AC90, 8 bytes long. Data: < > 0C AC 15 00 00 00 00 00 {188} normal block at 0x00159E20, 8 bytes long. Data: <| > 7C 9D 15 00 00 00 00 00 {187} normal block at 0x00159DD8, 8 bytes long. Data: <T > 54 9D 15 00 00 00 00 00 {183} normal block at 0x00158F68, 8 bytes long. Data: < > C4 8E 15 00 00 00 00 00 {182} normal block at 0x00158F20, 8 bytes long. Data: < > 9C 8E 15 00 00 00 00 00 {178} normal block at 0x001580B0, 8 bytes long. Data: < > 0C 80 15 00 00 00 00 00 {177} normal block at 0x00158068, 8 bytes long. Data: < > E4 7F 15 00 00 00 00 00 {173} normal block at 0x001571F8, 8 bytes long. Data: <Tq > 54 71 15 00 00 00 00 00 {172} normal block at 0x001571B0, 8 bytes long. Data: <,q > 2C 71 15 00 00 00 00 00 {168} normal block at 0x00156340, 8 bytes long. Data: < b > 9C 62 15 00 00 00 00 00 {167} normal block at 0x001562F8, 8 bytes long. Data: <tb > 74 62 15 00 00 00 00 00 {164} normal block at 0x00155B30, 8 bytes long. Data: < Z > D4 5A 15 00 00 00 00 00 {162} normal block at 0x001559E0, 8 bytes long. Data: < Y > 84 59 15 00 00 00 00 00 {160} normal block at 0x00155890, 8 bytes long. Data: <4X > 34 58 15 00 00 00 00 00 {158} normal block at 0x00155740, 8 bytes long. Data: < V > E4 56 15 00 00 00 00 00 {156} normal block at 0x001555F0, 8 bytes long. Data: < U > 94 55 15 00 00 00 00 00 {154} normal block at 0x001554A0, 8 bytes long. Data: <DT > 44 54 15 00 00 00 00 00 {152} normal block at 0x00155350, 8 bytes long. Data: < R > F4 52 15 00 00 00 00 00 {150} normal block at 0x00155200, 8 bytes long. Data: < Q > A4 51 15 00 00 00 00 00 {148} normal block at 0x001550B0, 8 bytes long. Data: <TP > 54 50 15 00 00 00 00 00 {146} normal block at 0x00154F60, 8 bytes long. Data: < O > 04 4F 15 00 00 00 00 00 {144} normal block at 0x00154E10, 8 bytes long. Data: < M > B4 4D 15 00 00 00 00 00 {140} normal block at 0x00154C40, 16 bytes long. Data: < K > 0C 1D EF 00 02 00 00 00 01 00 00 00 88 4B 15 00 {139} normal block at 0x00154BF0, 14 bytes long. Data: <bad exception > 62 61 64 20 65 78 63 65 70 74 69 6F 6E 00 {138} normal block at 0x00154B88, 44 bytes long. Data: < h > F4 1C EF 00 00 00 00 00 68 F8 EE 00 18 F8 EE 00 {135} normal block at 0x00154A98, 16 bytes long. Data: <\ 0J > 5C 1C EF 00 02 00 00 00 01 00 00 00 30 4A 15 00 {134} normal block at 0x00154A30, 44 bytes long. Data: <D 8 > 44 1C EF 00 00 00 00 00 88 F7 EE 00 38 F7 EE 00 Object dump complete.
Le 14/09/13 03:42, Paul Morrison a écrit :
I am running a number of Boost threads communicating via bounded buffers. My programs seem to run properly, but I get a number of memory leaks, usually 4- and 8- byte areas, although a few are longer. As far as I can tell, they are coming from inside Boost, as there is no mention of lines in my code. OTOH, although my code runs fine, it is quite possible that there are subtle errors in it!
I am using _CRTDBG_MAP_ALLOC, which is being used correctly as it detected one area of my own that I was not freeing up, and that has been fixed.
I am running VC++ 2010 Express on a 64-bit machine.
Here is my memory leak display - I tried setting a few of the numbers as breakpoints, using_CrtSetBreakAlloc(), but most of them did not cause breaks.
The first one broke at a new in > boost::detail::basic_condition_variable::get_wait_entry() Line 180 + 0x7 bytes C++
Why wouldn't this get freed up?!
Note: <bad exception > looks ominous - where is it coming from?!
Hi, the issue seems to be introduced in changeset https://svn.boost.org/trac/boost/changeset/40478 improved lifetime management of thread data. - - struct externally_launched_thread_deleter - { - externally_launched_thread* thread_data; - - externally_launched_thread_deleter(externally_launched_thread* thread_data_): - thread_data(thread_data_) - {} - - void operator()() const - { - intrusive_ptr_release(thread_data); - } - }; - - } - + } thread thread::self() @@ -156,5 +185,4 @@ externally_launched_thread* me=detail::heap_new<externally_launched_thread>(); set_current_thread_data(me); - this_thread::at_thread_exit(externally_launched_thread_deleter(me)); } return thread(boost::intrusive_ptr<detail::thread_data_base>(get_current_thread_data())); @@ -375,17 +403,4 @@ I would need some time to analyze the changes. Please could you create a Trac ticket? Best, Vicente
Le 14/09/13 15:24, Vicente J. Botet Escriba a écrit :
Le 14/09/13 03:42, Paul Morrison a écrit :
The first one broke at a new in > boost::detail::basic_condition_variable::get_wait_entry() Line 180 + 0x7 bytes C++
Why wouldn't this get freed up?!
Note: <bad exception > looks ominous - where is it coming from?!
Hi,
the issue seems to be introduced in changeset https://svn.boost.org/trac/boost/changeset/40478 improved lifetime management of thread data.
<snip>
I would need some time to analyze the changes.
Please could you create a Trac ticket?
Best, Vicente
Forget my message. It has nothing to be with condition_variable :( Vicente
participants (2)
-
Paul Morrison
-
Vicente J. Botet Escriba