Why not override -[FilOpExecutor retain] temporarily? While it'll be very verbose and is very non-recommended in production code, it'll allow you to set a breakpoint and figure out what's trying to retain the object. Sure, it'll be a lot of effort to track it down... but hey, that's why debugging is hard.
On Thu, Oct 16, 2014 at 5:45 PM, Riccardo Mottola < [email protected]> wrote: > Hi, > > I am still struggling to tweak GWorkspace's FileOpInfo and its executor: I > think it is "leaking". > > I'm referring to: > Operation/FilewOpInfo.m > > If I put a NSLog() in in the FilOpExecutor dealloc (around line 770), I > can expect that eventually it should be reached, right? else, it is leaking. > > I'm a bit new to the use of tasks and DOs and the memory retaining inside. > > the setPorts: method does an alloc and a release, so it is balanced. > > The thread gets detached in detachOperationThread (line 316) > > Gregory added a NSThreadWillExitNotification observer, but at that point, > the executor is already dead, no point sending it a release, nothing will > happen. > > What else could be retaining the FileOpExecutor, perhaps the connection? > > Riccardo > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Ivan Vučica [email protected]
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
