Bug 627875 - memory leak in boost::thread_group
Summary: memory leak in boost::thread_group
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: boost
Version: 19
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Petr Machata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-27 09:17 UTC by Enrique
Modified: 2015-01-14 01:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-14 01:35:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Code snippet showing the memory leak (309 bytes, text/x-c++src)
2010-08-27 09:17 UTC, Enrique
no flags Details
Valgrind output for Fedora 14 alpha (1.83 KB, application/octet-stream)
2010-08-27 09:18 UTC, Enrique
no flags Details

Description Enrique 2010-08-27 09:17:10 UTC
Created attachment 441443 [details]
Code snippet showing the memory leak

Description of problem:

 I have detected a memory leak in boost::thread_group.
 I provide a small code snippet that shows the problem together with the valgrind report. I found the same bug in Fedora 13 and in Fedora 14 alpha.
 Probably it would be interesting that the fix comes from upstream.

Version-Release number of selected component (if applicable):
 
 1.44.0

How reproducible:

 Always

Steps to Reproduce:
1. Compile the code snippet:
    g++ boost_leak.cpp -o boost_leak -lboost_thread-mt

2. Execute valgrind:
    valgrind   ./boost_leak

3. Have a look at the memory report
  
Actual results:


Expected results:
 Clean Valgrind report.

Comment 1 Enrique 2010-08-27 09:18:11 UTC
Created attachment 441445 [details]
Valgrind output for Fedora 14 alpha

Comment 2 Denis Arnaud 2010-08-28 11:02:09 UTC
Apparently, Valgrind does not catch the moment at which the memory is freed (and it may not be memory leak). See the answer from Boost experts: http://lists.boost.org/Archives/boost/2010/08/170274.php

So, I'd suggest to run a server, based on your code, and to check whether the memory footprint increases.

But, based on another discussion (http://lists.boost.org/Archives/boost/2010/08/170142.php), which occurred in the Boost developer mailing list, and in which someone ran a server launching several hundreds of (Boost) threads, it seems that (at least that version of the) Boost.Thread does not leak memory.

Comment 3 Enrique 2010-09-02 15:15:33 UTC
 Well, running a server does not help because it seems it is a one-time memory allocation per process. So even if many thread_group's are created and destroyed, only a final memory leak is reported by valgrind.

 If it is fine with boost probably the ticket can be closed.

Comment 4 Bart Van Assche 2010-09-02 17:01:14 UTC
(In reply to comment #2)
> Apparently, Valgrind does not catch the moment at which the memory is freed
> (and it may not be memory leak).

I do not agree with the above statement. See also https://bugzilla.redhat.com/show_bug.cgi?id=629673 for the real cause of this leak.

Comment 5 Denis Arnaud 2010-09-02 18:11:22 UTC
(In reply to comment #4)
> See also https://bugzilla.redhat.com/show_bug.cgi?id=629673 for the real cause 
> of this leak.

So, that issue appears to be related more to pthread than to Boost, right?

Comment 6 Bart Van Assche 2010-09-02 18:21:04 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > See also https://bugzilla.redhat.com/show_bug.cgi?id=629673 for the real cause 
> > of this leak.
> 
> So, that issue appears to be related more to pthread than to Boost, right?

Since I have not yet found a statement in the POSIX spec about whether or not thread-local destructors must be invoked when the main thread exits, there are still three possibilities:
1. It is not specified in IEEE Std 1003.1 whether or not destructors of thread-local data must be invoked when the main thread exits.
2. The glibc implementation is POSIX compliant.
3. The glibc implementation is not POSIX compliant.

In cases (1) and (2) it is a Boost bug and in case (3) it is a glibc bug.

Comment 7 Bart Van Assche 2010-09-29 16:53:32 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > See also https://bugzilla.redhat.com/show_bug.cgi?id=629673 for the real cause 
> > > of this leak.
> > 
> > So, that issue appears to be related more to pthread than to Boost, right?
> 
> Since I have not yet found a statement in the POSIX spec about whether or not
> thread-local destructors must be invoked when the main thread exits, there are
> still three possibilities:
> 1. It is not specified in IEEE Std 1003.1 whether or not destructors of
> thread-local data must be invoked when the main thread exits.
> 2. The glibc implementation is POSIX compliant.
> 3. The glibc implementation is not POSIX compliant.
> 
> In cases (1) and (2) it is a Boost bug and in case (3) it is a glibc bug.

According to the information in https://bugzilla.redhat.com/show_bug.cgi?id=629673, the answer is (2) and hence this is a Boost bug.

Comment 8 Denis Arnaud 2010-10-02 20:50:40 UTC
As far as I understand, we are talking here of per-thread memory not fully cleanly released when the main thread exits. That does not seem to be a case of memory leak for which we should be much worried about. For instance, that "bug" will not incur memory leaks in servers, as the main thread does not exit.

Again, that is my understanding, supported by some Boost developers: http://lists.boost.org/Archives/boost/2010/09/171433.php

So, in that case, that "bug" is not that much worth to be "fixed". Unless I(we) have missed something?

Comment 9 Bart Van Assche 2010-10-03 07:11:41 UTC
(In reply to comment #8)
> As far as I understand, we are talking here of per-thread memory not fully
> cleanly released when the main thread exits. That does not seem to be a case of
> memory leak for which we should be much worried about. For instance, that "bug"
> will not incur memory leaks in servers, as the main thread does not exit.

Agreed, but:
- IMHO it would be a good idea to add a source code comment in the two source files libs/thread/src/pthread/once.cpp and libs/thread/src/pthread/thread.cpp that even when an application exit()s normally that it is possible that the destructor is not invoked, together with the a reference to the POSIX specs that explain this behavior (e.g. http://opengroup.org/onlinepubs/9699919799/functions/_Exit.html#tag_16_01_03_01).
- For some projects there is a rule that Valgrind must not report any "definitely lost" complaints. This makes sense because what is a leak-at-exit in one run can be a real memory leak in another run, and also because absence of "definitely lost" complaints in a run implies that there were no memory leaks in that run. When using such a policy, having libraries that do not comply is annoying.

> Again, that is my understanding, supported by some Boost developers:
> http://lists.boost.org/Archives/boost/2010/09/171433.php

The message you refer to has been written after comment #7 was added to this bugzilla entry, so it may be based on the information in the Red Hat bugzilla database.

Comment 10 Denis Arnaud 2010-10-03 09:33:05 UTC
(In reply to comment #9)
> - IMHO it would be a good idea to add a source code comment in the two source
> files libs/thread/src/pthread/once.cpp and libs/thread/src/pthread/thread.cpp

I'll make that suggestion to the Boost developer list. Thanks for having pulled out the references.

> > Again, that is my understanding, supported by some Boost developers:
> > http://lists.boost.org/Archives/boost/2010/09/171433.php
> 
> The message you refer to has been written after comment #7 was added to this
> bugzilla entry, so it may be based on the information in the Red Hat bugzilla
> database.

For whatever reason, mailman archives do not display the time zone next to the date and time. gmane does, as seen in:
http://thread.gmane.org/gmane.comp.lib.boost.devel/207952/focus=207954
Frank Mori Hess was quick to answer, bot not so quick as to answer the question before it was asked :)

Comment 11 Denis Arnaud 2010-10-03 11:23:49 UTC
(In reply to comment #10)
> > > Again, that is my understanding, supported by some Boost developers:
> > > http://lists.boost.org/Archives/boost/2010/09/171433.php
> > 
> > The message you refer to has been written after comment #7 was added to this
> > bugzilla entry, so it may be based on the information in the Red Hat bugzilla
> > database.

Sorry, I did not catch what you were trying to say. Yes, Frank (Mori Hess) has written the message (http://thread.gmane.org/gmane.comp.lib.boost.devel/207952/focus=207954) after comment #7 has been made... since he indeed answer to comment #7 (which I reported to him, and to the other developers of the Boost development dedicated mailing list)...

Comment 12 Enrique 2010-10-05 13:21:13 UTC
 As suggested in comment #9, for some projects the output of valgrind defines whether the project is "clean" or not. That's my case, so having this memory leak is a bit annoying. A possible workaround is to include a valgrind suppression, but fixing it would be more desirable of course..

Comment 13 Denis Arnaud 2010-10-08 20:45:36 UTC
(In reply to comment #12)
> ... having this memory leak is a bit annoying. A possible workaround is to
> include a valgrind suppression, but fixing it would be more desirable of
> course..

Do not hesitate to report your feedback upstream (i.e., to the Boost developers). Even better if you can provide them with a patch. As for whether they will accept it is another story.

Comment 14 Fedora Admin XMLRPC Client 2012-01-11 12:31:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Fedora Admin XMLRPC Client 2012-01-11 14:52:09 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Fedora End Of Life 2013-04-03 18:55:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 17 Fedora End Of Life 2015-01-09 16:20:11 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Petr Machata 2015-01-14 01:35:05 UTC
Closing as per Denis' comments.


Note You need to log in before you can comment on or make changes to this bug.