[fpc-devel] Need patch for bugs : 0011503 / 0009472

[Boian Mitov]

     Hi Florian,

FLock is not interface. There is no error with the FLock.
WriteLock is interface, and I have to destroy it before I destroy the FLock. 
The order of destruction is obviously crucial.
The error is the fact that WriteLock referenced object is not released when 
WriteLock is assigned to NIL. I have found a number of work arounds for 
this, but some will not work in more complex scenarious :-( . As I mentioned 
this is a very simple case where the bug is obvious.

  With best regards,
    Boian Mitov

--------------------------------------------------------------------
Mitov Software
http://www.mitov.com
--------------------------------------------------------------------


----- Original Message ----- 
From: "Florian Klaempfl" <florian at freepascal.org>
To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
Sent: Thursday, June 19, 2008 5:54 AM
Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472


> Boian Mitov schrieb:
>> Here is a code sniped that sows just one example of the problem:
>>
>> This is a very simple example of how important the order really is:
>
> Unfortunatly, I can quote only from the german delphi help: "Wenn Sie die 
> Referenzzählung nutzen wollen, dürfen Sie das Objekt nur als 
> Schnittstellenreferenz verwalten." It says, if you want to use the 
> reference counting, you might store the class only as interface reference. 
> I guess FLock is no interface?
>
> Further, how is in delphi ensured that WriteLock:=Nil; doesn't release 
> FLock?
>
>> We have even more crucial problems related with this. This is just a 
>> simple one:
>>
>> destructor  TALBasicAudioOut.Destroy();
>> var
>>  WriteLock : IOWLockSection;
>>
>> begin
>>  WriteLock := FLock.StopLock();
>>
>>  FInputPin.Free();
>>  FEnablePin.Free();
>>  FMasterPumping.Free();
>>  WriteLock := NIL;
>>  FLock.Free();
>>  inherited;
>> end;
>>
>> You can see that the WriteLock  MUST be released before the 
>> FLock.Free();,
>
> The .Free is probably the error here. If FLock inherits from 
> TInterfacedObject, calling release is the way to go.
>
>> otherwise you will have access violation, and this is a destructor, so 
>> the options are limited.
>>
>>  With best regards,
>>    Boian Mitov
>>
>> --------------------------------------------------------------------
>> Mitov Software
>> http://www.mitov.com
>> --------------------------------------------------------------------
>>
>>
>> ----- Original Message ----- From: "Michael Van Canneyt" 
>> <michael at freepascal.org>
>> To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
>> Sent: Thursday, June 19, 2008 5:16 AM
>> Subject: Re: [fpc-devel] Need patch for bugs : 0011503 / 0009472
>>
>>
>>>
>>>
>>> On Thu, 19 Jun 2008, Boian Mitov wrote:
>>>
>>>>    Hi Michael,
>>>>
>>>> Thank you! I will be looking into the code, and see if I can add the
>>>> functionality with some switch. We may redo the code, however it will 
>>>> probably
>>>> take well over a year for fully rewriting it all, and it may not be
>>>> necessarily a smart thing. Delphi unlike C++ does not have any form of
>>>> function or block enclosement, and the interfaces are the closest thing 
>>>> to
>>>> functional enclosement we have, aside from the error prone try/finally 
>>>> pair.
>>>> If we lose it, we lose a major development tool :-( . It surely 
>>>> downgrades the
>>>> Pascal language a notch. I hope however that sometime in the future we 
>>>> will
>>>> finally have a real functional enclosement in Pascal, but who know ;-) 
>>>> .
>>>
>>> I can see that you really want this feature, this is for sure.
>>>
>>> However, nowhere you write WHY you need this feature;
>>>
>>> The behaviour you seem to expect is wrong by definition.
>>>
>>> As stated:
>>> There are *no* leaks. The memory is freed at procedure exit;
>>>
>>> This is just a little later than what you expect. (you expect it right 
>>> after the :=Nil;)
>>>
>>> So WHY do you expect/need this behaviour ?
>>>
>>> What architectural decision makes this necessary ?
>>>
>>> I am asking this because I find it hard to believe that you would
>>> write conciously code which really depends on this feature.
>>>
>>> Michael.
>>> _______________________________________________
>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel