Strange EListError occurance (when accessing variable-defined index)

Question

Hi, I have a TList which stores some objects. Now I have a function which does some operations on that list:

function SomeFunct(const AIndex: integer): IInterface
begin
if (AIndex > -1) and (AIndex < fMgr.Windows.Count ) then
  begin
    if (fMgr.Windows[AIndex] <> nil) then
      begin
        if not Supports(TForm(fMgr.Windows[AIndex]), IMyFormInterface, result) then
          result:= nil;
      end;
  end
else
  result:= nil;
end;

now, what is really strange is that accessing fMgr.Windows with any proper index causes EListError... However if i hard-code it (in example, replace AIndex with value 0 or 1) it works fine. I tried debugging it, the function gets called twice, with arguments 0 and 1 (as supposed).

while AIndex = 0, evaluating fMgr.Windows[AIndex] results in EListError at $someAddress, while evaluating fMgr.Windws[0] instead - returns proper results ...

what is even more strange, even though there is an EListError, the function returns proper data ... and doesn't show anything. Just info on two EListError memory leaks on shutdown (using FastMM)

any ideas what could be wrong?!

Thanks in advance michal

Answer 1

There is no reason for it to throw an EListError if the index is correct. If an exception is thrown, there is no reason for it to not show and still return normal results.

Unfortunately it is hard to see what the problem is with this little information so I can only guess:

Maybe you're having multi threading issues? Maybe the exception does get thrown, but debugger does not stop on breakpoints? Maybe the leak is not from this code? Maybe it is a false leak report? Maybe fMgr references something different? Maybe the facts are different?

You could try turning on more debug information and have FastMM report callstacks or you could try compiling with Debug DCUs and trace into the TList code. And make sure Delphi stops on all exceptions. Maybe that will help in finding your problem.

Answer 2

I think you are just confusing the debugger in some way. Sometimes "clean", leak free code seems to generate a memory leak if there is a watch looking at a property, and evaluating that watch causes an exception. These aren't displayed to to the IDE they are handled by the debugger.

A case where this may happen is if you have a debugger showing fMgr.Windows[AIndex] before Aindex is intialised, or a watch on fMgr.Windows[0] before there are any items in the list.

Answer 3

Good answer - this worked for me

---

I think you are just confusing the debugger in some way. Sometimes "clean", leak free code seems to generate a memory leak if there is a watch looking at a property, and evaluating that watch causes an exception. These aren't displayed to to the IDE they are handled by the debugger.