On 29/08/2012 05:05, waldo kitty wrote: > On 8/28/2012 06:47, Bernd wrote: >> The pragmatic fix to he above problem was: >> >> procedure TConnection.OnTCPFail(ASocket: TLHandle; const Error: String); >> begin >> Self._AddRef; >> FDisconnectLock.Acquire; >> >> [...] >> >> FDisconnectLock.Release; >> Self._Release; //<-- now we will be freed exactly here! >> end; > > so adding that one line negates the previous .Free line(s)?? > > i'm still learning all this new-fangled stuff... i'm a (very) oldschool > procedural coder and having things popping into and out of existence whenever > they want to is something i'm still trying to wrap my head around :/ :( >
Notice the _AddRef call ? Thanks to this, the >>>> Self._AddRef;[Self.RefCount is now 2] [...] FBuddy.SetIncoming(nil); //[Self.RefCount is now 1] was: bug: this will free ourselves NOW!!! <<<< and after [...] Self._Release; // [Self.RefCount is now 0 and GC removes the TConnection from memory.] BTW, Frankly, would it not be easier/less error prone if the FDisconnectLock.[Acquire|Release] did that ? (i.e. increase/decrease the RefCount of Self as well as acquire/release the lock ?) It seems /logically/ correct : there is /one/ more activity associated to this object, so it can't be freed before it's done ? Curiously, L. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
