On 11/04/2010 18:37, Alexander Klenin wrote:
On Mon, Apr 12, 2010 at 02:02, Martin<[email protected]> wrote:
I think the patch is correct then. (When I found that FMarks was destroyed,
I overlooked that the TChartSeries holding it, were also destroyed)
destructor TChart.Destroy;
begin
FSeries.Free;
...
inherited Destroy;
end;
inherited destroy calls getChildren, which accesses FSeries.
Even that I would call suspicious, but I think the problem is deeper.
The crash still happens even if I comment out the call to inherited Destroy
in TChart.Destroy.
eh, removing that inherited call will get a lot of other trouble...
Also, the callstacks I get after the crash do not contain TChart.Destroy
you mean "not inherited destroy"?
This suggests that ComponentTreeView/ObjectInstector code
does call TChart.GetChildern after TChart.Destroy, and the patch I posted
works only because the freed memory is not reused yet during
the call to GetChildren.
If that was true, then it would suggest that some other component (which
is known to OI) must hold a pointer to TChart; and (on request) hand
that pointer to OI....
On the other hand: if you disabled the call to inherited destroy => then
the dead object would most certainly get a lot of calls.
in that inherited call your TChart notifies a lot of other components
(Owner, everyone who requested FreeComponent (which probably includes
OI)) that it is destroyed => if you prevent that, they will believe it
is still there....
This is why I asked for help -- I suspect there is a bug in
ComponentTreeView/ObjectInstector code, but there are only a few people
capable of understanding it, and I am not one of them.
Well neither am I.
But I am still reasonable convincent, that it is to do with destruction
order, and dangling references...
Martin
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
