
On Sat, Jan 20, 2007 at 01:02:56PM +0100, Roland Schwarz wrote:
pete@mu.org wrote:
It appears to come from this line in boost/lib/src/pthread.cpp: I suspect you mean file: boost/libs/thread/src/thread.cpp.
Doh! Sorry, you are correct.
Could it be that the leak is being created by using the tmp object in the thread creation? I've read advise about NOT doing that?
I am not sure if I understand you correctly. Could you please try to be more explicit?
Which tmp object are you refering to? Where did you read what?
Sorry again, as I was not correct when I said that. I spoke before I should have. I was not paying attention to the auto_ptr, it is not a tmp. However, It looks like thread_group::create_thread is really just calling pthread_create in my case. ie., Linux OS. Is is possible that this could be an issue with new/delete vs malloc/free? I'm pretty sure that pthread_create uses malloc, and on line 331 thread_group::~thread_group there is a delete taking place for all those pointers. thread_group::~thread_group() { // We shouldn't have to scoped_lock here, since referencing this object // from another thread while we're deleting it in the current thread is // going to lead to undefined behavior any way. for (std::list<thread*>::iterator it = m_threads.begin(); it != m_threads.end(); ++it) { delete (*it); } } I'm still relatively new to c++ and even newer to boost, so maybe I'm way off. However, I'm mentioning it because it seems to raise a flag with Effective C++'s recommendation. Also, I don't think even free'ing a joined pthread is necessary in the first place, so I'm kinda confused about what's going on here or what the effect might be. Any other ideas? Thanks, Pete
I guess your original sample exhibits the leak?
I'll try to reproduce locally: In order to get equivalent test conditions, could you post the exact steps you used to create and invoke the test?
I realized after reading your email again that 1.34 is what you specified, but I used 1.35. Would that be a problem?
No I don't expect so. They should currently be the same.
Roland
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users