I am battling an intermittent error. According to EurekaLog, the error occurs in this routine:
I am battling an intermittent error. According to EurekaLog, the error occurs in this routine:
procedure TTreeItem.Clear;
var
j: integer;
LinkedItem: TLinkedItem;
begin
for j:=0 to LeafSize-1 do begin
if Items[j] <> nil then begin
if Items[j] is TTreeItem then begin <---- exception thrown here
TTreeItem(Items[j]).Free;
Items[j] := Nil;
end
else begin
LinkedItem:=TLinkedItem(Items[j]);
while LinkedItem <> nil do begin
Owner.DestroyItem(LinkedItem.Value);
LinkedItem:=LinkedItem.Next;
end;
TLinkedItem(Items[j]).Free;
Items[j] := Nil;
end;
end;
end;
end;
The code seems all too simple. Items added are TTreeItems, so the test for whether the item is a TTreeItem is almost redundant, but the question is, how can an is test on the item throw an exception?
The code is taken from a Hash Trie implementation which is used in a third-party component, a version which is no longer supported.
I do not have the option of installing a current version of the component, and the problem, though intermittent, happens relatively often.
Update: We will be moving away from this component for new work, but at present (and in D2007) we must find a way to make this work.
This one is driving me crazy, which is why I am posting at 4:00 in the morning: I woke up trying to imagine solutions....
procedure TTreeItem.Clear;
var
j: integer;
LinkedItem: TLinkedItem;
begin
for j:=0 to LeafSize-1 do begin
if Items[j] <> nil then begin
if Items[j] is TTreeItem then begin <---- exception thrown here
TTreeItem(Items[j]).Free;
Items[j] := Nil;
end
else begin
LinkedItem:=TLinkedItem(Items[j]);
while LinkedItem <> nil do begin
Owner.DestroyItem(LinkedItem.Value);
LinkedItem:=LinkedItem.Next;
end;
TLinkedItem(Items[j]).Free;
Items[j] := Nil;
end;
end;
end;
end;
The code seems all too simple. Items added are TTreeItems, so the test for whether the item is a TTreeItem is almost redundant, but the question is, how can an is test on the item throw an exception?
The code is taken from a Hash Trie implementation which is used in a third-party component, a version which is no longer supported.
I do not have the option of installing a current version of the component, and the problem, though intermittent, happens relatively often.
Update: We will be moving away from this component for new work, but at present (and in D2007) we must find a way to make this work.
This one is driving me crazy, which is why I am posting at 4:00 in the morning: I woke up trying to imagine solutions....
Nicholas Ring Update: I have added CodeSite logging sufficient to establish that the HashTrie is in some way corrupted. A cell in the TTreeItem contains a non-nil value which does not point to an object. It then attempts to determine what kind of object is pointed to, and throws the AV.
ReplyDeleteAxolot suggests I try the latest version of their component, which I have done, but the trial version tries to insert two file names in the uses clause, and these files are not present. I'm getting only one reply a da on the support forums, so it's a very slow process.
I have tried, without success, to block the exception, and suffer the resulting leak. Very frustrating.
Bill Meyer Thanks for the update and I feel you frustration - At least you are on the road to fixing the problem. All the best!
ReplyDeleteNicholas Ring Thanks. Still slogging through the swamp. ;)
ReplyDelete