heaptrace unable to read file [solved]

[jbmckim]

Using heaptrace, I'm getting the attached error when I try to open a file (with line number) listed by heaptrace as being a problem. (i.e. Unable to read file <file name> <address>)  I'm not sure if this error is mapping to the source file or to the heaptrace file.  Ultimately, I don't care about that so much has to how to fix.    The source file in question compiles, runs, works per spec and opens successfully with an external editor.

As background: I'm in development right now (as opposed to maintenance) and am writing a lot of code. I take a time out at good stopping points and go back and clean up all my memory leaks.  There's usually a bit to do but I haven't seen this problem before.  Any ideas?

Thanks.

[Martin_fr]

Could you attach the heaptrc file? So I can try to reproduce this?

[jbmckim]

Sure,

Here it is as a 7z since .trc won't upload.

[jamie]

as far as I know HTrace isn't suppose to do anything until you exit however, I've seen it popup while executing code due to the fact that I corrupted the memory table.

 Heap trace will malfunction if you bleed over into other memory blocks because it loses control of the memory blocks and unexpected things like this happen..

 The reported line number may not even be the cause, it could be an effect of code elsewhere.

 I suspect that improper handling of memory objects is the cause.

[jamie]

Can you please provide a ZIP version of that file please.

7z is not a application I have installed.

[Martin_fr]

I will have to debug the leak-view code. So this may be a short while.

Just to be sure, you used the "load from file", rather than the paste clipboard? So we can exclude the clipboard screwing around with the line endings?

[Thaddy]

Did you go back and fixed all the warnings?

[jbmckim]

jamie - zip is attached
Martin_fr - if you're willing to wade through the source, take all the time you need
Thaddy - as above but more detail - this is one of those times when I'm cleaning all such things up.  So I'm only partially done cleaning.  I hit this "feature" pretty early on into the process. 

[jbmckim]

Update:

It probably wasn't clear from my first post that not all the file/line references failed.  Hopefully, that is clear from the trace file.  I was able to work all the way through this batch of memory leaks.  Note that many warnings still remain to dispatch!

I look forward to hearing what was going on with the file access problem.

[jamie]

it's obvious you are not releasing memory on some operations around that area of line numbers...

Also I assume you are not multi-threading at this time? Because it could be an issue with collision code.

 Without seeing some of the actual code that is generating this I would say you need to free up the resources you are creating..

 Most dynamic items do not release automatically, you need to do this, with the exception of managed items but I doubt you are using those in this case.
 
  So you need to check some code to see what is being created with the functions you are using, because they need to be released when you exit your app.

[jbmckim]

jamie - there are two real issues here. 

1) As stated in my previous post "I was able to work all the way through this batch of memory leaks."  My main leaks were caused by a TSpecList of objects where each object also contained an object.  The TSpecList is .Clear'ed and then .Free'ed. The main problem was that the sub-objects needed to be .Destroy'ed (i.e. at app close) prior to the TSpecList.  What hit me as odd in this was that the objects themselves were not presented as the problem but rather dynamic arrays they contained.  This made it a little confusing.  However, working from the top down, once I freed the sub objects the dynamic arrays they contain were no longer given as problems.  Heaptrc now returns nothing.

2) The second issue has more to do with HeapTrc itself.  A number of files referenced in the report could not be referenced from the Heaptrc form.  Attempting to do so would throw the error I attached above.  I suspect that will get look at in more detail as time passes.

[Martin_fr]

2) The second issue has more to do with HeapTrc itself.  A number of files referenced in the report could not be referenced from the Heaptrc form.  Attempting to do so would throw the error I attached above.  I suspect that will get look at in more detail as time passes.

That is the one I am on...

LeakView accepts quiet a few input formats that were accumulated over time.  The original code was never a charmer, and with more added.....

I recently noted some issues myself. So I am writing a unit test case for it now. And then fix it.

[Martin_fr]

I made some improvements: r61711 LeakView: fix various parsing issues

Still needs some major clean up....

[jbmckim]

I'm backtracking on old posts of mine.

I'm going to mark this solved with the idea that heaptrc could benefit from continued attention.  Thanks Martin_fr for picking some of this up.