Michal Rudolf wrote: > 2009-12-04 11:08:51, Joost 't Hart: > > >> But I do not look at that, as it does not ring the bell. Instead, I >> link-in a simple heap space reporter library between the application and >> any malloc/free/new/delete etc operation (hacked it myself, if you are >> interested, I will send it to you). So I rather monitor what memory the >> application claims (and releases) instead of what memory the OS actually >> provides. >> > But, your approach may not work if Tcl manages memory internally, that is, > some memory may be claimed to be taken by Tcl even though released by Scid. > > Of course, this would point to some problems with Tcl memory management. > >
Probably true, yes. I am largely ignorant of how Tcl works - can even barely read it - but I guess my lib is unaware of all memory operations that Tcl does by itself. Pity, but one cannot have it all :-) Besides, I think what Pascal intended to say is that there are - in this case - two ways of implementing something like malloc(). At "C" level, that is. One can simply use libc or hook into the Tcl memory manager. The latter seems to do a better job in avoiding memory fragmentation. Yet, the trick I do is quite effective. With each heap operation, the lib sends a token to stdout, containing info on __FILE__ and __LINE__, operation, buffer pointer and size. Listening on stdout sits a utility, constructing and monitoring the heap map. So it does report in case of release of a buffer that was "never" allocated (which is at least suspicious; note that this does not occur in Scid). Of course, "underneath" the lib the original memory manager is still doing its work. But as far as the analysis of the lib is concerned it is irrelevant which memory manager that is (you simply plug in one) and how efficiently it performs its task. Joost. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
