Never completes

Never completes

I created a "development test" toexercise a set of classes from production code that are responsible for a task that leaks memory every time it is done, according to process explorer.

The code seems to leak 2MB each time and does not stop until the system memory is exhausted.

When I run the development test in debug, it completes and exits with code 0 within 5 minutes.
When I profile it with Inspector XE, the anlysis never completes, not even if I leave it over night.

What should I be trying? What should I look at?

I've also tried the Inspector configuration option to step through with the debugger to a break point for start of profiling and another breakpoint for stop of profilingand that exercise causes inspector to throw an unhandled exception and crash.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


Can you let me know your operating system (Assuming Windows*) and
version. Can you also provide the Intel
Inspector XE command line being ran. If
you are using the GUI interface, you can obtain the command line by clicking on
the show command Line button on the Analysis Type tab. Are you running Intel Inspector XE with
Visual Studio integration? If so, which version?

Does the application crash or exhaust system memory outside of Intel
Inspector XE when the application is compiled normally? Any clarification you can provide in this
area is appreciated.

Does the application being analyzed, run as system and / or is it
a Windows service for example? any
information here may help diagnose the behavior and determine next course of

Are you Running Intel Inspector XE 2011 update 9? If not you may wish to apply update 9 which may
be available to you at the Intel Registration center
after logging into your account.

If needed, are you able to provide a minimal zipped up solution
reproducer where we may be able to replicate the issue and run tests?

- Rob

Analysis can fail even with 24GB RAM if you have too many samples. My cases shouldn't be typical, but I have to go to the lower part of the properties menu to set an expected time of 3 hours in order to limit the sampling rate and be successful with a 1 or 2 minute sampling run. I guess if you don't have 4GB RAM or less you might have trouble even with a 100MB .tb6 file. If you capture the command line, you could increase the sample-after values before running it as another way to limit your sampling.

Running on
Windows Server 2003 SP2 through VMWare (not sure version)
Using Visual Studio 2008 Integration
Application did not crash or exhaust memory outside of inspector

Command Line:
inspxe-cl -collect mi3 -knob resources=true -knob memory-growth=true -knob stack-depth=16 -knob analyze-stack=true -knob duplicate-elimination=true -mrte-mode=native -module-filter-mode=include -app-working-dir "C:\Perforce\trunk\ATMS2\Server\Development Tests\DevTest_StatusClient" --search-dir sym=c:/Perforce/trunk/ATMS2/bin/Debug --search-dir sym=C:/Perforce/trunk/ATMS2/Server --search-dir sym=srv*C:/Windows/symbols --search-dir sym=srv*c:/windows/symbols* --search-dir sym=C:/Perforce/trunk/ATMS2/DBServer/UtilityBlade/src/Debug --search-dir sym=c:/Perforce/trunk/ATMS2/ThirdParty/DcomPerm/Debug -- c:\Perforce\trunk\ATMS2\bin\Debug\DevTest_StatusClient.exe

The code being tested usually was taken from a multi tier system and narrowed down to a contained executable which calls some ATL/COM components, which run in process and out of process.

the Intel software Manager says I am running Intel Inspector XE 2013 beta Update 1, but it also says I have the latetest. I will try to redownload.

I cannot provide source, as my employer would get upset. It would also require all kind of COM configuration.


Can you attempt a mi1 (detect leaks) level analysis and also set
the stack depth to 8 instead of 16? Does
the behavior change? In the same environment,
does Intel Inspector XE complete an analysis on other applications? This information may help narrow the scope of the problem.



I see you may have a related Forum thread here. Let me know if you are proceeding with that
forum thread or wish to continue this one.
Peter mentioned aspects related to COM support and some
suggestions. My approach is to simplify and
narrow the possible scope in an attempt to determine a path forward. That may not be possible in this situation. Of course, if you have a simplified reproducer
we can build in VS, that would be optimal.
We would then be able to run various tests to determine scope and a possible
path forward.

- Rob

Leave a Comment

Please sign in to add a comment. Not a member? Join today