Spelt
commented
8 years ago Hi Carlo
Nice! I used EurekaLog to detect and squash memory leaks, I thought I got them all but maybe QA is more specialized.
TResultpoint which seems simple but was/is the culprit of many leaks. I did not have in mind the clone technique here as I wanted (for debugging purposes) as close as possible with the .Net port. I did add and committed the clone technique for the issue you mentioned yesterday.
Good to hear that the ARC compiled apps are safe, love ARC :-)
In the coming branch v_3.0 TResultpoint did change a little bit so be aware of that but I do think its a great idea to change TResultpoint descendant to TInterfacedObject. It will make things cleaner which can never be a bad idea.
Op 12 jul. 2016, om 17:10 heeft Carlo Sirna notifications@github.com het volgende geschreven:
Hi, I made my test program run inside the AQTime memory profiler: this tool does some interesting things: 1) reports memory leaks at the end of the application run, including the call stacks of the procedure where each leaked memory block has been allocated 2) overwrites memory content of every instance whenever it gets deallocated, so any code accessing it after its deallocation fails miserably, instead of reading the old data 3) checks memory overflows (accesses of data beyond the limits of its allocation).
Thanks god we have only problems 1 and 2.
To be precise: when the application seems to be running correctly it does because it is having memory leaks... I tried to fix memory leaks (caused mostly by arrays not being cleared during destruction... maybe intentionally), but I started having the same block of memory deallocated multiple times or being accessed (for reading) after the deallocation
for what I have seen most of the problems are related to instances of TResultPoint being passed around inside TArray<> collections member variables of different objects during the calculation.
Do you have in mind the "clone" method I suggested to add yesterday? ok, the problem is much like the same, but it is widespread.
This code works perfectly as far as it is being compiled for a language that does automatic reference counting and garbage collection of the instances, but it gives problems for old-style compilers I think that the most clean way of maintaining the same logic also Win32/Win64 this is to make TResultPoint a TInterfacedObjet descendant and use a IResultPoint interface instead handling directly TresultPoint instances, so we can mimic the automatic garbage collection provided by ARC using reference couning of instances...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Spelt/ZXing.Delphi/issues/27, or mute the thread https://github.com/notifications/unsubscribe/AMEt1ZCDgKCThgNXYwc-6FHMlh_I8x72ks5qU65qgaJpZM4JKgCJ.
Hi, I made my test program run inside the AQTime memory profiler: this tool does some interesting things: 1) reports memory leaks at the end of the application run, including the call stacks of the procedure where each leaked memory block has been allocated 2) overwrites memory content of every instance whenever it gets deallocated, so any code accessing it after its deallocation fails miserably, instead of reading the old data 3) checks memory overflows (accesses of data beyond the limits of its allocation).
Thanks god we have only problems 1 and 2.
To be precise: when the application seems to be running correctly it does because it is having memory leaks... I tried to fix memory leaks (caused mostly by arrays not being cleared during destruction... maybe intentionally), but I started having the same block of memory deallocated multiple times or being accessed (for reading) after the deallocation
for what I have seen most of the problems are related to instances of TResultPoint being passed around inside TArray<> collections member variables of different objects during the calculation.
Do you have in mind the "clone" method I suggested to add yesterday? ok, the problem is much like the same, but it is widespread.
This code works perfectly as far as it is being compiled for a language that does automatic reference counting and garbage collection of the instances, but it gives problems for old-style compilers I think that the most clean way of maintaining the same logic also under old-style compilers it is to make TResultPoint a TInterfacedObjet descendant and use a IResultPoint interface instead handling directly TresultPoint instances, so we can mimic the automatic garbage collection provided by ARC using reference couning of interfaces...