(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote: > For consistency, you cannot keep traces when tracing is disabled. > The free() must be enabled to remove allocated memory blocks, or > next malloc() may get the same address which would raise an assertion > error (you cannot have two memory blocks at the same address).
That seems like an a quirk of the implementation, particularly since the actual address is not returned to the user. Nor do I see any way of knowing when that allocation is freed. Well, unless I missed it... I don't see how to get anything beyond the return value of get_traces, which is a (time-ordered?) list of allocation size with then-current call stack. It doesn't mention any attribute for indicating that some entries are de-allocations, let alone the actual address of each allocation. > For the reason explained above, it's not possible to disable the whole > module temporarly. > Internally, tracemalloc uses a thread-local variable (called the > "reentrant" flag) to disable temporarly tracing allocations in the > current thread. It only disables tracing new allocations, > deallocations are still proceed. Even assuming the restriction is needed, this just seems to mean that disabling (or filtering) should not affect de-allocation events, for fear of corrupting tracemalloc's internal structures. In that case, I would expect disabling (and filtering) to stop capturing new allocation events for me, but I would still expect tracemalloc to do proper internal maintenance. It would at least explain why you need both disable *and* reset; reset would empty those internal structures, so that tracemalloc could shortcut that maintenance. I would NOT assume that I needed to call reset when changing the filters, nor would I assume that changing them threw out existing traces. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
