[Lazarus] RFH: AV when deleting TAChart from the form

[Martin]

On 11/04/2010 18:37, Alexander Klenin wrote:
> On Mon, Apr 12, 2010 at 02:02, Martin<lazarus at mfriebe.de>  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