Growl 1.3.1 Mist memory leak?

[Kristoffer Peterhaensel]

Hey.

Tried to post here a couple of times already. But it seems
to not have showed up. So here we go again.

I have been working on a small application that uses Growl
to show some notifications from our server product. So I
had it running over night for some stress testing. And
after about 15 hours with a notification every 5 seconds.
The memory consumption has gone from around 2 MB at launch
to 88 MB. And most of that seems to be 11k+ instances of
GrowlMistView and similar numbers of other objects I do
not use in my code - but would make sense for the Mist
notification.

Now the question is if this is me doing something wrong.
Or is there a leak?

I am not really sure what I *could* do wrong to leak
memory in Growl. Since all I do is call
+[GrowlApplicationBridge notifyWithTitle:
description:
notificationName:
iconData:
priority:
isSticky:
clickContext:]

It is not returning anything I need to release. And I
can't really see any other way to do the setup.

/Kristoffer Peterh�nsel

[Chris Forsythe]

We filter the list with posts from new people on the first emails due to spam concerns. That's why your 3 messages sat in a queue for an hour or 3. :)

-- 
Chris Forsythe

@The_Tick

/Kristoffer Peterhänsel

--

You received this message because you are subscribed to the Google Groups "Growl Development" group.

To post to this group, send email to growl-de...@googlegroups.com.

To unsubscribe from this group, send email to growl-developm...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.

[Daniel Lee Siemer]

I do see we have a leak, but not as bad as what you have described, maybe 30-40 MB for 11k notes in BeepHammer (I know, still not good, and we will work at some point to improve that), but certainly not all 11k mist views, at least with the 1.4 and 2.0 sdk's.  There are some significant changes to mist in the 2.0 sdk (we replaced the positioning controller, so notes will behave better and more reliably when using mist and a high rate of notes), but 1.4 has not really changed much from 1.3.x to my knowledge.  If you would like to help us diagnose your issue a bit more since Im not sure how to reproduce what you are seeing at this point, it would be greatly appreciated.

[Kristoffer Peterhänsel]

On Wednesday, 23 May 2012 17:53:49 UTC+2, Daniel Siemer wrote:

I do see we have a leak, but not as bad as what you have described, maybe 30-40 MB for 11k notes in BeepHammer (I know, still not good, and we will work at some point to improve that), but certainly not all 11k mist views, at least with the 1.4 and 2.0 sdk's.  There are some significant changes to mist in the 2.0 sdk (we replaced the positioning controller, so notes will behave better and more reliably when using mist and a high rate of notes), but 1.4 has not really changed much from 1.3.x to my knowledge.  If you would like to help us diagnose your issue a bit more since Im not sure how to reproduce what you are seeing at this point, it would be greatly appreciated.

Hehe. Yeah I do appear to have some leaks of my own as well. That is why I am running the tests ;)

Right now I am focusing on the other parts of the application that is not using Growl. And I have just dropped ARC as it seems to not be working as very well for me (might be the mixed C++, Objective-C and Objective-C++ I work with). So I just need to have everything sorted out.

But if it is leaking I suppose there is not a lot I can do about that. And just hope it is not going to be a big issue.

[Daniel Lee Siemer]

Ah, indeed, we have not tested the framework much in an ARC environment, and mixing of languages while doable can be full of pitfalls in the memory management area.  If you can better track down what is leaking in the framework, of course we will be glad to fix it =)

--
You received this message because you are subscribed to the Google Groups "Growl Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/growl-development/-/fjpfVtgb7_gJ.