Talk:Digging memory leaks of EiffelStudio

--Jocelyn 15:17, 2 April 2007 (CEST) I think "memory leaks" is not only about "once" feature, it may occurs with C interfacing too (when objects might by adopted and frozen for C purpose), and there is also the case with graphical interface using "agent" keeping references to unused objects.

--Ericb 09:35, 3 April 2007 (CEST): Is there a way to get the same kind of window as the GC statics mem map window for the application currently debugged in EiffelStudio debugger (rather than for the EiffelStudio application itself)? It would be much more convenient than having to pollute our application code with calls to MEMORY.memory_map, in the same vein we don't pollute our code with io.put_string but rather use the debugger object browser to inspect values.

--manus 14:57, 5 April 2007 (CEST) At the moment, the memory map can be done within one application. Doing it in the debugger would not be very efficient at all since it would require EiffelStudio to know about all the objects in the program and in addition causing a leak by keeping track of them. Indeed each time an object is monitored by EiffelStudio, it is not a candidate for garbage collection even if no other objects reference it.

--Ericb 09:16, 6 April 2007 (CEST): I'm just interested in the number of objects per type. Why can't the debugged application send this information to EiffelStudio on request. No need for EiffelStudio to know about each and every object of the application.

--manus 11:52, 6 April 2007 (CEST) This could be made to work since this would only be sending string data. I thought you wanted the actual relations which can be computed by the tool you mention in EiffelStudio.