Baffled by an "if" that doesn't work

[Henppy]

Ok, so I don't know what's happening here... You know, "the compiler is always right" versus  "I'm right and this thing is doing it wrong!"... This time I swear I'm right.

Here's the code, lets see if any of you gentlemen can throw me a bone because I'm lost:

Code: [Select]

procedure TGenericList.CheckIndex(Index: integer);
begin
  if Index >= FItemCount then
      raise EListIndexOutOfBounds.Create('Index ' + IntToStr(Index) + ' outside of bounds [0..' + IntToStr(FItemCount - 1) + ']');
end;

Where FItemCount is:

Code: [Select]

private
     FItemCount: integer;

Please see the attached image, the exception is thrown when Index = 1 and FItemCount = 2.

I don't know how to debug this... so any help is welcome.

I'm using 1.2.0 BTW, but as far as I know it's the same FPC compiler version.

[Never]

is not possible to reproduce the behavior with the code provided.
but are you sure that FItemCount in the procedure in question is the one with the value 2?
if is the same then

seems like a wrong order on cheking your index

[Henppy]

Yep, just quadruple-checked, no other thing called neither FItemCount or Index that could be reached in there.

I can upload the code, problem is that this is happening in the middle of code parsing by SynEdit... So debugging is not as trivial as hitting F9.

Worst thing is that the exception is sort of "swallowed", not thrown to be cached at all,  the program just hangs there.

[howardpc]

Can you attach the full code for TGenericList?

[Henppy]

Attached the file in question. Also uploaded the code to: https://dl.dropboxusercontent.com/u/70266302/src.zip

Now, if you're willing to run this thing. First of all thank you, and second, here's what you need to do:

1) The problematic code is in uContainers.pas line #157.
2) Type a letter, debugger will stop but ignore it this time.
3) Press enter so you add a new line after the letter you just added. Debugger stops again and here is where the problem is.

Thanks all.

[Never]

i will look your code but you might find faster this
[
some where in your code you are doing this

increasing your count var
your cheking the index-->if you are here then you migh have a value 2 in count but is not correct because the item is not added yet
so if you use the count to determine a possition to add your items this will lead to an error

and last you add an item or whatever
]

[Henppy]

I run into this when I was adding a method that would remove items:

Code: [Select]

procedure TGenericList.RemoveFrom(Index: integer);
begin
  CheckIndex(Index);
  FItemCount := Index;
end;

So at this point there's no modification of anything expect the integer FItemCount... that's what I think at least.

BTW, the sequence of events would be:

1) The user is adding a line.
2) The SynEdit parser will do its thing, but first, it wants to get rid of any tokens stored on a list. So it calls the RemoveFrom method.
3) RemoveFrom method just decreases the FItemCount field.

[Never]

belive it or not your program produces no errors here
 so just close evrerthing reset the debuger or even better reset and reboot and try it
 maybe the debuger is stuck somewhere it happens to me often
the timer is one thing to have your eye on

[Blaazen]

My experience: debugging generics is pretty tricky.

Try to put writeln or MessageDlg right before the condition, to see what really happens there.

Code: [Select]

procedure TGenericList.CheckIndex(Index: integer);
begin
writeln(Index, FItemCount);
MessageDlg(...);
  if Index >= FItemCount then
      raise EListIndexOutOfBounds.Create('Index ' + IntToStr(Index) + ' outside of bounds [0..' + IntToStr(FItemCount - 1) + ']');
end;

[Never]

found another bug
file : uKerboscriptHighlighter
Line:151

Code: [Select]

procedure TKerboscriptHighlighter.SetLine(const NewValue: string; LineNumber: integer);
begin
  inherited;
  CurrentLine := PChar(NewValue);
  CurrentLineIndex := LineNumber;
  fEditor.TokenLines.CropLines(CurrentLineIndex); <----can be nil here
  if fEditor <> nil then
  begin
    //0.3
    fEditor.TokenLines[CurrentLineIndex].Clear;
    if LineNumber < fEditor.LineIndex_Syntax then
      fEditor.LineIndex_Syntax := LineNumber;
  end;
  PosEnd := 0;
  Next;
end;

[howardpc]

If you're still getting problems I suggest you put the code from CheckIndex back into Remove() and RemoveFrom(), and comment CheckIndex out; and then the debugger will show you values from the stack of the actual called routine where it will be easier to pinpoint why the "if" seems to misbehave (if it indeed does) in the SynEdit context where you are using it, context outsiders can't easily reproduce exactly.

[Henppy]

Ok, so here's what I think is happening. I inserted a ShowMessage and guess what, nothing showed up. I Run > Clean up Build files, run again an the dialog box showed up. Went back, removed the line, saved, run again... the dialog box showed up again.

So apparently Lazarus or FP are not re compiling the source even if it was modified.

Even more strange, I go and introduce an error, Ctrl-F9 an the thing complains. Good. Delete the error, compile, run, dialog box still showing up even when it's not in the code!

I don't remember tinkering with the settings, but could it be some setting?

EDIT: Thanks Never! Quite blunt mistake on my part.

[Never]

Checked your project settings
under project options/ mischellaneous the setting [Always build even if nothing is changed is not set]
maybe this will make a dif for you

[Blaazen]

So apparently Lazarus or FP are not re compiling the source even if it was modified.

Even more strange, I go and introduce an error, Ctrl-F9 an the thing complains. Good. Delete the error, compile, run, dialog box still showing up even when it's not in the code!

I experienced this too. See my mail on ML: http://lists.lazarus.freepascal.org/pipermail/lazarus/2014-July/088017.html

Yesterday, I thought it's OK (I downloaded the latest trunk) but it happened again.

I was not able to create a simple demo for bugreport, it happens with larger projects only.

[Blaazen]

I reported it. Lazarus sometimes ignores changes and run old version of executable.

http://bugs.freepascal.org/view.php?id=26659