Re: Re: Re: Leak when using boost threads under VC .NET using usi ng statically linked CRT
-----Original Message----- From: Alan Saunders Sent: 22 November 2004 17:24 To: 'boost-users@lists.boost.org' Subject:
Hmmm no linker errors or warnings. I've set my main exe to statically link. if i use the version of threads that statically links to msvcrt71 or dynamically to msvcrt71.dll it doesn't seem to make any difference. Our boost libraries where compiled here for msvcrt71 and i can confirm this.
As i say if my main exe uses msvcrt71.dll then theres no leak.
Are you using tls code? TLS currently (as to my knowledge) contains a "intentional" leak which however is harmless. Could you post the messages? Did you track down the leak?
Hi Roland 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. 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. Sorry which messages would you like me to post? Haven't tracked down the leak yet. My problem is solved for the time being by using msvcrt71.dll as i said before. However it would be nice to be able to using the static lib. 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! Looking at function it certainly isn't as trivial as thread. One thing i have noticed is that there is an option to get function to use "new" instead of std::allocator with the macro BOOST_NO_STD_ALLOCATOR. (function_template.hpp). I haven't got round to trying this yet though. Alan
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
MSVC prints out some messages about the memory leak when ending the
Hi,
a note regarding the memory leak (8+24 bytes) that you found - see bellow.
----- Original Message -----
From: "Roland Schwarz"
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
#include at the top of the file and _CrtDumpMemoryLeaks(); at the bottom.
Independent of the loop size I get a constant leak of 24 + 8 bytes.: Detected memory leaks! Dumping objects -> {89} normal block at 0x002F27A8, 24 bytes long. Data: < w > C0 09 FD 77 FF FF FF FF 00 00 00 00 00 00 00 00 {88} normal block at 0x002F2A18, 8 bytes long. Data: < '/ > A8 27 2F 00 01 CD CD CD Object dump complete.
I am not sure where this comes from at he moment, since I think the tls is not even used internally yet (the once function might be the culprit, but I don't think it is used in your example.)
At least the leak seem to be constant.
I have a similar leak on Windows with the dll version of boost threads 1.32. Perhaps this is the same leak reported by gast128 in the thread "Memory leak reported using threads library". A mutex is created in DLLMain -> on_process_enter -> init_threadmon_mutex. It seems that this mutex is never deleted and there is no comments that this is intentional. On Windows the size of the mutex is 8 bytes and it creates a CRITICAL_SECTION in its constructor - 24 bytes. ....
Roland
Best regards Stefan
Stefan Shishkov wrote:
I have a similar leak on Windows with the dll version of boost threads 1.32. Perhaps this is the same leak reported by gast128 in the thread "Memory leak reported using threads library". A mutex is created in DLLMain -> on_process_enter -> init_threadmon_mutex. It seems that this mutex is never deleted and there is no comments that this is intentional. On Windows the size of the mutex is 8 bytes and it creates a CRITICAL_SECTION in its constructor - 24 bytes. ....
Indeed this seems to be the same. The reason for it's existence however is the same as for the documented one. Michael are you listening? I remember vaguely that Michael having found a way to do without it. Am I remembering correctly? Roland
"Roland Schwarz"
Stefan Shishkov wrote:
I have a similar leak on Windows with the dll version of boost threads 1.32. Perhaps this is the same leak reported by gast128 in the thread "Memory leak reported using threads library". A mutex is created in DLLMain -> on_process_enter -> init_threadmon_mutex. It seems that this mutex is never deleted and there is no comments that this is intentional. On Windows the size of the mutex is 8 bytes and it creates a CRITICAL_SECTION in its constructor - 24 bytes. ....
Indeed this seems to be the same. The reason for it's existence however is the same as for the documented one. Michael are you listening?
Yes, I am. I'm just back from several days of vacation, which is why I didn't reply before.
I remember vaguely that Michael having found a way to do without it. Am I remembering correctly?
I briefly had a solution that didn't use one, but rejected it as incorrect; the reasons are brought up in the comment starting at line 41 of tss_hooks.cpp. We should certainly look into deleting the mutex and fixing the leak. Mike
participants (4)
-
alansa＠ati-uk.com -
Michael Glassford -
Roland Schwarz -
Stefan Shishkov