On Thu, Jul 22, 2010 at 12:45 AM, Peter Hosey <[email protected]> wrote: > On Jul 21, 2010, at 22:40:09, Stephen J. Butler wrote: >> My guess is that in some situation newValue is ending up null. > > That's how it looked to me, too, so the patch I just sent adds an explicit > check for this.
I can see it now. I don't know if this made it into any bug reports, but we don't just see duplicate "link down" messages... they come in pairs! Turns out that for the first one SCDynamicStoreCopyValue() returns null, and then for the second one immediately after the first SCDynamicStoreCopyValue() returns a dictionary! So whatever OS process behind the scenes that is triggering it, the "change" is that the watched key becomes null then becomes inactive. My code doesn't trigger it because it is never null the first change after you pull the cable. And on subsequent, duplicate error messages you're already in an inactive state so it has no reason to enter a code path where it CFRetains(). Now that I look closer at -airportStatusChange: there are null checks there too for newValue. I'll test your patch tonight, but I think it will do the trick. -- 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.
