Error 204 or Invalid Pointer when using SetLength to 0 on a Dynamic Array

[Zvoni]

Noone asked the question: What is happening within DoSomething?
I agree with Thaddy: Probably Use after Free

[MarkMLl]

I agree with Thaddy: Probably Use after Free

Fixable using FreeAndNil()  >:-)

MarkMLl

[MaxM74]

It's an error in my code, but it made me understand that during the resetting of the list the compiler decreases the RefCount of the Interfaces and therefore if it reaches zero they are freed.
If I want to free them when I say I have to derive from TNoRefCountObject.

Take a look on Attachments placing breakpoints in the destroys.

[MarkMLl]

I'm hoping that Thaddy takes a look at that since he's been so insistent that it's easily fixable, and since I claim little expertise in interfaces etc.

However I think it's fair to say that refcounts are fairly arcane, and I've only once before come across a case where somebody was considering the refcount of an interface at the application level (and IIRC that was related to getting property values while debugging, so in itself was fairly arcane).

I'm very glad that we're collectively getting this sorted out...

MarkMLl

[cdbc]

Hi
If OP is in charge of the interfaces in the libraries, the solution should be simple: switch the interface declaration to {$interfaces CORBA} or ofc use the 'TNoRefcountObject' to instantiate the interfaces...
If not he could try to store the interface references in a weak reference i.e.: a pointer and the typecast it when needed?!?
Regards Benny

[MarkMLl]

If OP is in charge of the interfaces in the libraries,

OP's already said

I cannot do something like ... because the code of those who implement the interface is in libraries, I only maintain a list of implementers.

MarkMLl

[MaxM74]

Hi
If OP is in charge of the interfaces in the libraries, the solution should be simple: switch the interface declaration to {$interfaces CORBA} or ofc use the 'TNoRefcountObject' to instantiate the interfaces...
If not he could try to store the interface references in a weak reference i.e.: a pointer and the typecast it when needed?!?
Regards Benny

I think I'll use them without RefCount, already the fact that I don't know when they will be released worries me.

I also had problems declaring a private field of an interface type in a class that implements another interface, the field is inexplicably freed before the class is freed causing me quite a few problems.
So I decided to always derive from TNoRefCountObject

The Structure is like this:

Code: Pascal  [Select][+][-]

1. TMyParams = class(TInterfacedObject, IParams)
2.    //private fields, etc
3.    //implementation of IParams methods
4. end;
5.  
6. TAnotherClass = class(TInterfacedObject, ITaker)
7.   protected
8.     rParams: TMyParams;
9.    //implementation of ITaker methods
10.    
11.    constructor Create;
12. end;
13.  
14. constructor TAnotherClass.Create;
15. begin
16.   inherited Create;
17.  
18.   rParams :=TMyParams.Create;
19. end;
20.  

[MarkMLl]

I think I'll use them without RefCount, already the fact that I don't know when they will be released worries me.

OK but as specific questions (to try to anticipate what others might ask):

* Is the library yours, i.e. could you modify it if that appeared appropriate?

* Is it simply loaded into the FPC/Lazarus project, are you statically linking it, or is it demand-loaded?

MarkMLl

[Thaddy]

Fixable using FreeAndNil()  >:-)

MarkMLl

As Basil Fawlty said, "Don't mention the war."

[Zvoni]

As Basil Fawlty said, "Don't mention the war."

And as Manuel would answer: "¿Qué?"

[MaxM74]

I think I'll use them without RefCount, already the fact that I don't know when they will be released worries me.

OK but as specific questions (to try to anticipate what others might ask):

* Is the library yours, i.e. could you modify it if that appeared appropriate?

* Is it simply loaded into the FPC/Lazarus project, are you statically linking it, or is it demand-loaded?

MarkMLl

The Libraries are dinamically load. Think of an application that loads plugins from a folder.
I'm on the Application side, plugins could be written in any language.
For this reason I store a field of type Interface in the list record.

In "self-written" libraries and internal plugins I will certainly derive from TNoRefCountObject 

[MarkMLl]

The Libraries are dinamically load. Think of an application that loads plugins from a folder.
I'm on the Application side, plugins could be written in any language.
For this reason I store a field of type Interface in the list record.

In "self-written" libraries and internal plugins I will certainly derive from TNoRefCountObject 

So if I interpret that correctly, you're basically inferring a certain reference counting behaviour on the part of the libraries/plugins you're using.

I'm definitely not saying you're wrong doing so. If anybody's at fault it's the supplier of the external binary who (presumably) hasn't documented things adequately.

MarkMLl