Recent

Author Topic: Error 204 or Invalid Pointer when using SetLength to 0 on a Dynamic Array  (Read 3536 times)

Zvoni

  • Hero Member
  • *****
  • Posts: 2472
Noone asked the question: What is happening within DoSomething?
I agree with Thaddy: Probably Use after Free
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

MarkMLl

  • Hero Member
  • *****
  • Posts: 7104
I agree with Thaddy: Probably Use after Free

Fixable using FreeAndNil()  >:-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MaxM74

  • New Member
  • *
  • Posts: 14
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

  • Hero Member
  • *****
  • Posts: 7104
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

cdbc

  • Hero Member
  • *****
  • Posts: 1350
    • http://www.cdbc.dk
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
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE5 -> FPC 3.2.2 -> Lazarus 2.2.6 up until Jan 2024 from then on it's: KDE5/QT5 -> FPC 3.3.1 -> Lazarus 3.0

MarkMLl

  • Hero Member
  • *****
  • Posts: 7104
If OP is in charge of the interfaces in the libraries,

OP's already said

Quote
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MaxM74

  • New Member
  • *
  • Posts: 14
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.  
« Last Edit: June 20, 2024, 09:32:55 am by MaxM74 »

MarkMLl

  • Hero Member
  • *****
  • Posts: 7104
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 15192
  • Censorship about opinions does not belong here.
Fixable using FreeAndNil()  >:-)

MarkMLl
As Basil Fawlty said, "Don't mention the war."
Of course the national anthem of the U.S.A. was written by Jimi Hendrix, didn't you know that?

Zvoni

  • Hero Member
  • *****
  • Posts: 2472
As Basil Fawlty said, "Don't mention the war."
And as Manuel would answer: "¿Qué?"
One System to rule them all, One Code to find them,
One IDE to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
Code is like a joke: If you have to explain it, it's bad

MaxM74

  • New Member
  • *
  • Posts: 14
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  :-X

MarkMLl

  • Hero Member
  • *****
  • Posts: 7104
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  :-X

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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018