Re: Memory increasing even when in debug-break

Hi Jeffrey,

Thank you for the prompt response. I will read through the links you
provided, but in the meantime I thought I'd give you an update.

I'm using the VS.Net debugger, I will try windbg instead and let you know.

I should also add that the app is a commercial app (www.priorganizer.com)
(although the code causing the leak has not been released for obvious
reasons). The problem occurs running in either .net 1.1 or 2 (I tried both).

Also the #bytes in all heaps is not increasing, so it seems to be an
unmanaged leak. Looking in perfmon both private bytes and I/O writes/s is
increasing continuously.

As I mentioned, a call to GetProcessByName seemed to trigger the continuous
leak of 20k/s, even though the method returned and the debugger was in
break. However, after looking through the code for GetProcessByName in
reflector and trying out bits of code in that implementation, I have got the
leak down to a call to RegQueryValueEx, querying for HKEY_PERFORMANCE_DATA.
It seems that as soon as I run this native method it returns 0 (success),
but then starts to leak and doesn't stop.

This is the code that triggers the continuous leak:

int size = 0x1f400 * 2;
IntPtr buffer = Marshal.AllocHGlobal((IntPtr) size);
int lpcbData = size;
IntPtr hkey = (IntPtr) (-2147483644); // performance_data
int errorCode = RegQueryValueEx(hkey, "Global", null, null, buffer, ref
lpcbData);
Marshal.FreeHGlobal(buffer);

However if I try this same code in a different app, I see no such memory
issue.
Have you ever heard of this problem before?

Thanks greatly for your time.
John
RiaForm Technology

""Jeffrey Tan[MSFT]"" <jetan@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:LP$Bxm5ZHHA.3664@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi John ,

Based on my understanding, your complex pure managed C# application is
experiencing memory leak which is indicated by "Private Bytes" counter
from
PerfMon. Even strange, your application event leaks while the debugger
breaks your application. If I have misunderstood you, please feel free to
tell me, thanks.

Actually, there are 2 types of memory leak in .Net: native leak and
managed
leak. The "Private Bytes" increases without reduce indicates that there is
memory leak in your application. Then you should check if ".NET # of Bytes
in all Heaps" counter also increases during the leak. If it also increases
without reduce, it means a managed memory leak. Otherwise, there is a
native leak(for example, in the FCL or even CLR native code). Please refer
to the links below for more details:
"I have a memory leak!!! What do i do? (defining the "where")"
http://blogs.msdn.com/tess/archive/2005/11/25/496899.aspx
"Debugging Memory Problems"
http://msdn2.microsoft.com/en-us/library/ms954591.aspx

I recommend you to give it a check.

More interesting is the debugger breaks while memory still increasing
issue. Can you tell me what debugger you are using to break your
application, VS debugger or Windbg? If you are using VS debugger, the only
possibility is caused by the activity of the debugger help thread. VS
debugger leverages a special debugger help thread in debuggee process to
get information of the managed process and to execute certain debugging
operations. I suspect while the debugger breaks the debugger help thread
is
still allocating memory, which causes the memory increase. Anyway, this is
merely a guess. Please refer to the link below for more details:
"Special threads in CLR "
http://blogs.msdn.com/yunjin/archive/2005/07/05/435726.aspx
"Implications of using a helper thread for debugging"
http://blogs.msdn.com/jmstall/archive/2004/10/13/241828.aspx

To prove my thought, I would recommend you to use windbg to attach and
break your application, will the memory still increase? Windbg uses native
Win32 debugging service. It normally issues a "int 3" software
interrupt(software breakpoint) in the debuggee, which causes the CPU to
stop all the threads(including the thread that performs GC, finalizer) in
your application. Since there are no running threads in your process, the
memory should not be touched by anybody(threads). You may give it a try.

Additionally, you may use Process Explorer to monitor if any threads are
still activating while your debugger breaks the application. This will
help
to reveal which thread is responsible for the memory increasing problem.

I will wait for your further test result, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.



.

Relevant Pages

  • Re: Some debugging tool to find references to freed memory
    ... The same company are responsible for MemProof which is a *free* heap memory ... and resource 'leak' debugger: ...
    (borland.public.delphi.non-technical)
  • Re: ofstream and locales: how do they use heap memory?
    ... so the same "leak" was reported. ... After calling ... in memory; I just ran the program in a debugger to see the difference. ...
    (microsoft.public.vc.language)
  • Re: MDAC memory leak
    ... Most libraries place the decision of when to free ... There's a capability of breaking on a particular memory allocation, ... leak 500 objects, on the second test I leak 3, because I fixed the bug). ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: MDAC memory leak
    ... Also when we used some of the memory leak tools suggested on microsoft site ... A mutex is a considerably less efficient synchronization ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: Memory leak in the Driver
    ... Paul G. Tobey wrote: ... driver development, it's most likely that you are at fault. ... The QFE has no impact on the leak but one thing is sure, ... i am sure that all the memory that i am allocating in my driver is ...
    (microsoft.public.windowsce.platbuilder)
Loading