Attaching to process?

Attaching to process?

Imagen de maitrebart

Is it possible to collect for memory leaks (or deadlocks/races) by attaching to a process?

publicaciones de 7 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de admin

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.

Imagen de Peter Wang (Intel)
Quoting maitrebart Is it possible to collect for memory leaks (or deadlocks/races) by attaching to a process?

"Attach to Process" feature is only available for VTune Amplifier XE 2011.

For Inspector XE, the tool should monitor whole running period of application, from start.

Regards, Peter

Imagen de zoharl3

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.

Imagen de robert-reed (Intel)

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
Imagen de Krupesh D.

Is there any way I can collect memory leaks of process running on the system?
I am using Inspector XE 2013.

Regards,
Krupesh D

Imagen de Peter Wang (Intel)

Cita:

Krupesh D. wrote:

Is there any way I can collect memory leaks of process running on the system?
I am using Inspector XE 2013.

Regards,
Krupesh D

No. You only can check memory leaks on the process, which was launched by the tool.

Inicie sesión para dejar un comentario.