[Boost-users] Re: Re: Re: Leak when using boost threads under VC .NET using usi ng statically linked CRT

[ala...@ati-uk.com]

 

-----Original Message-----
From: Alan Saunders
Sent: 22 November 2004 17:24
To: 'boost...@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

 

 

[Roland Schwarz]

ala...@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 <stdlib.h>
#include <crtdbg.h>

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 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


_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Stefan Shishkov]

Hi,

a note regarding the memory leak (8+24 bytes) that you found - see bellow.

----- Original Message -----
From: "Roland Schwarz" <roland....@chello.at>
Newsgroups: gmane.comp.lib.boost.user
Sent: Tuesday, November 23, 2004 12:32 AM
Subject: Re: Re: Re: Re: Leak when using boost threads underVC .NET using
usi ng statically linked CRT

...

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

[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? 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? I remember vaguely that
Michael having found a way
to do without it. Am I remembering correctly?

Roland

[Michael Glassford]

"Roland Schwarz" <roland....@chello.at> wrote in message
news:41A5F5B4...@chello.at...

> 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