The unknown autorelease pool (mis)behavior is coming from the 30- second timer created in GrowlApplication.m which exists because of the memory retention behavior the system is idle.
Relevant zombie thread: On May 10, Evan Schoenberg wrote: > On May 10, 2007, at 9:27 PM, Peter Hosey wrote: > >> On May 10, 2007, at 16:30:07, Evan Schoenberg wrote: >>> It turns out that autorelease pools don't pop regularly without >>> events coming into the application... which is part of the >>> explanation for the inexplicable leaks. >> >> Yeah, Ken Ferry mentioned that to me on IRC a long time ago. The >> suggested solution, IIRC was to periodically create an “other” >> event and put it into the event queue. >> >> I remember doing something about implementing that, but I don't >> remember what or whether it got committed. > > *nod* It rang a distant bell when I realized that was what was going > on. The solution I committed a little while ago just embeds an > autorelease pool and recreates it every 30 seconds. If an 'other' > event is cleaner somehow, I'm of course fine with that, too :) In > the process of the leaks cleanup I did this week, most of the > critical sections have now been enveloped in their own autorelease > pool for immediate memory clearance, so it's generally minimal > numbers of objects involved. I've implemented the 'other' event solution in [4296], my first commit to the new Google Code repo. -Evan On Aug 18, 2009, at 9:25 AM, Matt Massicotte wrote: > > Disclaimer: I work for Apple. So far, I haven't even seen a reason to > need to discuss unpublished API. Especially since it sounds like this > problem may have existed before snowleopard. I'm sure this can be > worked out without having to call in the lawyers :) > > Thanks for the dSYMs. Of course, now that have them, I'm having a > hard time catching leaks with Growl addresses in them. I just > recently updated my Google+Growl module, and perhaps that has changed > the behavior slightly. However, leaks still do occur. From the types > of objects, and the few backtraces I can see, it all appears to be > related to DO and events. The warnings appear to happen a few seconds > after the Google+Growl notifications occur, the leaks occur almost > immediately when the notifications are shown. > > They all seem to be in NSThread contexts. Are there any NSThreads you > use that do not have autorelease pools? It has been a long time since > I've looked at DO, but it looks like something is being routed to the > runloop in a thread, handled, but isn't surrounded by a pool. Perhaps > the pool is drained/released before the connections are all closed? > > Matt > > On Aug 17, 11:04 am, Peter Hosey <[email protected]> wrote: >> On Aug 17, 2009, at 07:08:24, Matt Massicotte wrote: >> >>> I can reproduce and see the leaks easily within Instruments, but I >>> don't have symbols for GrowlHelperApp. >> >> They're not linked anywhere yet, but there's a tarball of dSYM >> bundles >> for each of the last couple of releases: >> >> http://growl.info/files/Growl-dSYM-1.1.5.tbz >> http://growl.info/files/Growl-dSYM-1.1.6.tbz >> >> Theoretically, as long as you put the bundles in a place where >> Spotlight can find them (such as a subfolder of Documents), >> Instruments should use them automatically. If not, try placing >> GrowlHelperApp.app.dSYM next to GrowlHelperApp.app (in >> Growl.prefPane/ >> Contents/Resources). > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Growl Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en -~----------~----~----~----~------~----~------~--~---
