- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it possible to collect for memory leaks (or deadlocks/races) by attaching to a process?
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's hard to do if you don't have access to the initial state and there's very little closure on allocations in an already running process. Consider the difficulty. At the moment of attachment, some number of memory allocations are sure to have already been committed. Without a record, there's no list to check off when memory is returned to leave a residue of unreturned requests. A tool could start memory tracking at the point of attachment, but the same problem exists at the other end of the test run: which of the recorded allocations is still out because the service is still using it and which are leaked memory? Such problems lower the confidence level of memory leak results and make it hard to justify coding efforts for such partial results. Similar arguments can be made for race detection and knowing who was the last writer of every written memory location.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting maitrebart
Is it possible to collect for memory leaks (or deadlocks/races) by attaching to a process?
For Inspector XE, the tool should monitor whole running period of application, from start.
Regards, Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I don't buy that. You should be able to test the memory from any snapshot of a time frame, to any other snapshot at a later time. If I require to test a dll, which is ran by a complicated app, or I need to test for leaks before the app ends at a specific duration, I should be able to do that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, attaching Intel Inspector to a process at some arbitrary point in its executionand testing a DLL before the app ends are two very different tasks. Whereas in the former, when Intel Inspector begins its analysis it has no clue regarding what came before, what memory allocations were made, where their boundaries lie, or even how many allocations have been made--forget leak testing and bounds testing on any allocations that occurred before the attach. Picking out a particular DLL (or a set) for testing assumes that the tool was there from the beginning (at least of the DLL run) and gives the tool a chance to capture such allocation data over the duration of DLL activities. And coincidentally, Intel just released Intel Inspector XE 2011 for Windows* Update 5 to provide just such a feature:
- Enhanced module inclusion/exclusion capability when configuring projects for analysis - for example, you can inspect specific modules and disable inspection of all other modules, or disable inspection of specific modules and inspect all other modules
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there any way I can collect memory leaks of process running on the system?
I am using Inspector XE 2013.
Regards,
Krupesh D
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Krupesh D. wrote:No. You only can check memory leaks on the process, which was launched by the tool.Is there any way I can collect memory leaks of process running on the system?
I am using Inspector XE 2013.Regards,
Krupesh D
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page