L
Laura Stern
Guest
Re #1, I tried this yesterday and again today. It works just fine for me. So I don't know what's going on there. But I still don't understand the larger point. Yes, knowing the INSTANTIATING-PROCEDURE gives you some context, but again, this doesn't explain why something is leaking. I presume, the persistent procedure is started up and left running for a reason. What are the conditions under which it should be shut down? How do you even know whether any particular procedure should be around at any particular point? What does any of this have to do with the instantiating procedure? As I said, the proc that creates something may not be the code responsible for destroying it. That is the kind of use-case information we would need to know and is entirely missing from this conversation. Also, this is not information that is available in most programming languages (none that I know of). Therefore it seems suspect that it should be necessary. Finally: Generally, tools for finding memory leaks are used during development, not at deployment time. Yes, I understand that bugs get out there. But it sounds like this is some regular practice of instrumenting code for finding stray persistent procedures in a deployed application. Of course, I may be misinterpreting again.
Continue reading...
Continue reading...