VC STL - Leak after using setlocale

Author

Leak after using setlocale

Peter

2005-02-14, 9:11 pm

It appears as though there is a memory leak in the STL after using
setlocale(). The code below does not leak if setlocale() is not
called, however in its current state when setlocale() is called it
leaks. Can anyone please help !?!!!

[Using VC 6.0 SP6]

#include <fstream>
#include <locale.h>

using namespace std;

int main(int argc, char* argv[])
{
int n = 0;

setlocale(LC_CTYPE, "");

while(n < 100)
{
n++;
fstream x("c:\\boot.ini");
x.close();
}

return 0;
}

Pete Becker

2005-02-14, 9:11 pm

Peter wrote:
> It appears as though there is a memory leak in the STL after using
> setlocale().

How did you determine that there is a leak?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Pete Becker

2005-02-14, 9:11 pm

Pete Becker wrote:
> Peter wrote:
>
>
>
> How did you determine that there is a leak?
>

I should have mentioned: often what looks like a leak is an artifact of
the technique used to detect leaks. Code that messes with locales is
particurly prone to this problem, because C++ locale facets are
allocated lazily and destroyed very late in the shutdown cycle. Very few
leak detectors get this right.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

Doug Harrison [MVP]

2005-02-14, 9:11 pm

Peter wrote:

>It appears as though there is a memory leak in the STL after using
>setlocale(). The code below does not leak if setlocale() is not
>called, however in its current state when setlocale() is called it
>leaks. Can anyone please help !?!!!
>
>[Using VC 6.0 SP6]
>
>#include <fstream>
>#include <locale.h>
>
>using namespace std;
>
>int main(int argc, char* argv[])
>{
> int n = 0;
>
> setlocale(LC_CTYPE, "");
>
> while(n < 100)
> {
> n++;
> fstream x("c:\\boot.ini");
> x.close();
> }
>
> return 0;
>}

What happens if you get rid of your loop and <fstream> #include? What is the
text of the leak report? Does it sound like the spurious leaks described
here?

http://groups-beta.google.com/group...37756da516a8a43

--
Doug Harrison
Microsoft MVP - Visual C++

Peter

2005-02-14, 9:11 pm

Sorry I didn't say what I used.

I used Task Manager, because the loop it tight, you can watch it
escalate in the process tab of task manager (if you have the Memeory
Usage, Memory Delta and VM columns selected).

It you comment out the call the setlocale the process has a steady
memory usage.

--Peter

Doug Harrison [MVP]

2005-02-14, 9:11 pm

Peter wrote:

>Sorry I didn't say what I used.
>
>I used Task Manager, because the loop it tight, you can watch it
>escalate in the process tab of task manager (if you have the Memeory
>Usage, Memory Delta and VM columns selected).
>
>It you comment out the call the setlocale the process has a steady
>memory usage.

After increasing your loop limit from 100 to 1000000, I see what you mean.
It does look like a leak. I tried using the _CrtXXX heap debugging functions
but was unable to find a leak. Putting your fstream stuff in its own block
and dumping leaks around it reveals no leaks at all; setting a checkpoint
before the loop and dumping leaks after the fstream block yields endless
identical output that looks like this:

Dumping objects ->
{97} normal block at 0x00324500, 512 bytes long.
Data: < > 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
{74} normal block at 0x00324A90, 16 bytes long.
Data: <@wL > 40 77 4C 10 01 00 00 00 00 00 00 00 00 00 00 00
{60} normal block at 0x00322E10, 33 bytes long.
Data: < C -------------> 00 43 00 CD CD CD CD CD CD CD CD CD CD CD CD CD
{59} normal block at 0x00322DB8, 40 bytes long.
Data: < |L > 14 7C 4C 10 16 00 00 00 00 00 00 00 00 00 00 00
Object dump complete.

So the debug heap is too blunt an instrument to determine what's going on.
Possibly the library is using special allocation techniques that bypass
debug heap tracking, or it's acquiring resources directly from Windows that
it isn't releasing. Perhaps something like Purify could help pinpoint the
bug.

As a workaround, instead of specifying LC_CTYPE, you can use LC_ALL. In
addition, I did not observe this problem in VC 7.1.

--
Doug Harrison
Microsoft MVP - Visual C++

Sponsored Links