Re: Leak after using setlocale

From: Doug Harrison [MVP] (dsh_at_mvps.org)
Date: 02/11/05


Date: Fri, 11 Feb 2005 11:59:31 -0600

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


Relevant Pages

  • Re: socket connect call hangs
    ... Also I am not calling WSACleanup inside the loop. ... I even tried to trace for leaks using Process explorer, ... Volodymyr M. Shcherbyna, blog: http://www.shcherbyna.com/ ...
    (microsoft.public.win32.programmer.networks)
  • Fixing Memory leak in ATL
    ... My atl activex container leaks memory one time every time I run the program. ... normal block at 0x00D51810, 328 bytes long. ...
    (microsoft.public.vc.atl)
  • Re: Memory leak with Inline::C
    ... Also sprach Anno Siegel: ... > binary representation of the argument), but the loop leaks. ... > the loop runs out. ... > void by_inline(int x) { ...
    (comp.lang.perl.misc)
  • Re: CWinApp memory and destructor timing
    ... don't do anything in a window class's destructor that ... CrtMessageWindow is on the call stack, and apparently you never got the ... Here's the remaining leaks, and the much shorter call stack on exit. ... normal block at 0x003DB5E0, 1035 bytes long. ...
    (microsoft.public.vc.mfc)
  • Re: CWinApp memory and destructor timing
    ... don't do anything in a window class's destructor that ... CrtMessageWindow is on the call stack, and apparently you never got the ... Here's the remaining leaks, and the much shorter call stack on exit. ... normal block at 0x003DB5E0, 1035 bytes long. ...
    (microsoft.public.vc.mfc)