alansa@ati-uk.com wrote:
<> In order to clear random influences from other areas of the software i'm working on, I have created a simple program with the code that i listed before. nothing else, no tls code.
Sorry, I did not see your code, because the threading of the message display was in wrong order. I have seen it now.
The intentinal leak would be harmless if it did not keep increasing. If I let the program run for long enough i will run out of memory.
I don't think you are affected by this leak at all.
Sorry which messages would you like me to post?
MSVC prints out some messages about the memory leak when ending the program.
Usually they are helpful in tracking down the leak. (At least they give
a first hint.)
As I have seen you are still using 1.30 of boost. I would recommend to
upgrade to 1.32 (if possible).
In 1.32 the ability to statically linking to your code has been
reintroduced.
At least you could try your threading example with this version.
I did this right now but constrained the loop to 1000 iterations.
I used:
#define CRTDBG_MAP_ALLOC
#include
I replace the code in the loop which constantly starts and stop threads with my own code that did the same thing. This code was pretty much the same as the code for boost::thread using the windows api functions. This did not leak. However the big difference between my code and boost::thread is that my code didn't use boost::function. Therefore I suspect the leak could be in there!
What I don't understand is your mentioning of the boost::function lib. Where do you think it is getting used in your example? Roland