QC Bug?

From the crash, it looks like it's not closing sockets after it uses them. Does this happen immediately, or after a long time of operation? Are you updating quickly? (several times per second) Can you trim out all the fluff, and reproduce the problem with a small subset of patches (that you could then post for further inspection)?

I've whipped up a simple Image Downloader that repeatedly reloads the same image, and I'm able to get it to leak memory pretty reliably, but haven't crashed it yet. When the composition is stopped, or the patch is disabled, the memory gets reclaimed, so it's perhaps a bug where they're not releasing a pool when they should or something.

(Image Downloader shares ancestry with the RSS Downloader and XML Downloader -- the problem, according to your crash, is in the ancestral parts, so I think the other patches will exhibit similar properties)

It's updating every 30 seconds. It takes about 20 minutes to occur.

I've been testing it without updating via the LFO patch and it seems to be running with no trouble. Perhaps I'll just increase the time intervals for it to update.

Stupid XML patch.

Yeah, after some more analysis, this looks like it'll get you eventually no matter how infrequently you update it.

Looking for some workarounds for you...

I was thinking of maybe using the shell command patch to run wget to download the feeds, and inputting them from there. But that would... totally suck.

Ok, got some notes back from Troy:

Troy wrote:
Yep, good catch.

Kevin says, "I see. Images got added to the cache when it's supposed to be inactive."

Definitely a bug.

Thanks guys, Troy

("Kevin" above is Kevin Quennesson, the new Pierre Latour ;)

So, according to Apple, the bug is only located in the Image Downloader patch.

I modified my OOM sample composition to load XML's to verify this, and it appears to be correct -- XML loading doesn't seem to leak memory.

So, back to the drawing board with tracking this down.

(Any chance you can fling the composition my way for further testing? It will be kept confidential.)

I'll send it right away. It won't populate the data correctly since it's pulling from internal sources, but it should be enough to inspect it.

Thanks for doing the leg work for me, I definitely appreciate it.

The interesting thing is even if I stop the composition and restart it, the issue continues to occur. I have to fully exit QC to get it to work again.

And, I just found this out, if I try to open any other compositions when this happens, it says it's unable to open it, with no other information. So maybe it's an issue with QC itself?

I am curious if you were to restart with whatever renderer is at the end of the chain in "off/false" mode, if it would clear. I semi doubt it... but on some more complex qtz's I have put together where I am really trying to get fps up (before any kind of monitoring tool like performance inspector), it seemed that toggling "macros" off is OK, but that toggling the renderers off was always "better". That could be placebo, but I don't think so. I've used a lot of the "image loader at blinding speeds" thing (loading images onto kineme3D objects)... and I would always toggle off the 3D renderer if it would go "offscreen" as it seemed to not only run better for "normal reasons" but also because of the aforementioned, slow grinding halt.

This thread has been extremely fruitful.