I'm instrumenting my application with TracyAllocS and TracyFreeS, which looks great and is already very insightful! :smile:
However, I'm having a problem somewhere, and Tracy reports:
While I understand the message, I don't know where in my code the problem is. Yet, I believe the Tracy Client actually has the information of the stack available of where the attempted TracyFreeS happened. Even in case one uese TracyFree (i.e., without the S suffix and no callstack), still just the point in the code where the TracyFree is would also be helpful.
Reporting this info would be very useful, as I don't see any way to debug this, as the Tracy server running in my application doesn't do any checking, and happily continues execution.
TLDR: So, in summary, what I believe is possible and would be very helpful:
In case of a Free without an Alloc: report the source location, and callstack if available, of the Free.
In case of an Alloc at the same address as a previous Alloc without a corresponding Free: report the source location (and callstack) of the previous Alloc for which the Free is missing, and the source location (and callstack) of the current Alloc.
Potentially the "memory pool" can be indicated as well, in case somebody is choosing a memory pool ID dynamically at runtime (and thus the source location alone doesn't reveal which one).
slomp
commented
6 months ago
I'm instrumenting my application with
TracyAllocSandTracyFreeS, which looks great and is already very insightful! :smile:However, I'm having a problem somewhere, and Tracy reports:
While I understand the message, I don't know where in my code the problem is. Yet, I believe the Tracy Client actually has the information of the stack available of where the attempted
TracyFreeShappened. Even in case one ueseTracyFree(i.e., without theSsuffix and no callstack), still just the point in the code where theTracyFreeis would also be helpful.Reporting this info would be very useful, as I don't see any way to debug this, as the Tracy server running in my application doesn't do any checking, and happily continues execution.
TLDR: So, in summary, what I believe is possible and would be very helpful:
Freewithout anAlloc: report the source location, and callstack if available, of theFree.Allocat the same address as a previousAllocwithout a correspondingFree: report the source location (and callstack) of the previousAllocfor which the Free is missing, and the source location (and callstack) of the currentAlloc.Potentially the "memory pool" can be indicated as well, in case somebody is choosing a memory pool ID dynamically at runtime (and thus the source location alone doesn't reveal which one).