The Data Loader only scans the folder when the input path changes. It creates the output structure, then starts a background thread that progressively loads the images found within the folder hierarchy, updating the output structure as and when necessary. That thread stops when complete.
The QTZ does frequently change the input path, but only once every minute or so, and I'm fairly certain there are no leaks in the plugin - although I may well be wrong. If anyone's curious (or fancies stealing some source code), here's the Xcode project to the DataLoader plugin. http://upload.clayinteractive.co.uk/data/20110720150948-37388-DataLoader-20110720(1.2).zip Thanks! A. On 20 Jul 2011, at 14:38, George Toledo wrote: > Are you constantly scanning with your Data Loader plugin, or have you built > in an option to disable scanning once you've retrieved your data? I'd look at > that in regards to the memory issue. > > > > > On Wed, Jul 20, 2011 at 8:03 AM, Adrian Ward <adr...@clayinteractive.co.uk> > wrote: > > Hey vade > > Thanks for the thoughts - most appreciated. > > No image ports to/from the actual QTZ, just lots of images coming from custom > plugins, and going through JavaScript patches before being spat out in other > structures for rendering. The biggest potential culprit is a Data Loader > plugin that scans a folder hierarchically and returns a massive NSDictionary > filled with strings, images and structures of strings and images (etc). I'm > fairly certain there's no leaks in that plugin (having watched Object > Allocations carefully) but I'm convinced there's a leak somewhere internal to > QC, or OpenGL, or the NVIDIA/ATI drivers as a result of what it's doing. > Maybe 30% of the time I have crashes, I've also seen lots of malloc error 12s > in the log, so I know I'm pushing capacity (yes, the app is 32 bit). > > With NSZombies, the problem happens much quicker but it's still the same. > Very often the last thing the app spits out before SIGBUS'ing is "Could not > allocate register file: 12", which I'm finding it hard to know what this > means, other than it's another malloc error 12 (out of memory). > > Another potential culprit is a different plugin (StyledTextPlugin, one that > you've helped me with before) that uses WebKit to render a HTML string. It > uses an NSAttributedString which is created from a chunk of HTML using > WebKit, but this has to be done on a separate thread to avoid corrupting QC's > rendering pipeline. Because WebKit doesn't seem to be thread-safe, on some > crashes the backtrace is convoluted to say the least - and I'm not convinced > this isn't causing the problem either. > > Oh, I've also seen QC crash in the same way - so it's nothing to do with my > app specifically. > > Currently my not-so-ideal solution is to allow the app to crash quietly and > focus on relaunching it as quickly and seamlessly as possible - not ideal. > > Is it worth me sharing an Instruments trace, or is that mostly a useless > gesture? > > Thanks and all the best > > > Ade. > > > > On 18 Jul 2011, at 18:22, vade wrote: > > > Are you feeding images into published input image ports, or pulling images > > out of published image ports, or is everything handled internally a single > > QTZ? > > > > Try enabling NSZombies and see if you can re-create the crash or leak of > > objects. Does this happen consistently at the same point in your code, on > > app launch for example, or is it totally inconsistent? Is your app 32 bit? > > are you hitting a memory limit? Have you checked for leaks at all? > > > > Does yoru 3rd party plugin handle image processing? > > > > The thread overhead is afaik "well known" for quicktime, especially AIC and > > modern codecs that can use multiple decode threads. I often see tons of > > threads in apps like VDMX, because of pre-rolling, etc, and I dont think > > they get cleaned up quickly either. > > > > > > > > On Jul 18, 2011, at 12:05 PM, Adrian Ward wrote: > > > >> > >> Hi all, > >> > >> I'm starting to see an increase in sporadic crashes of an app we've > >> written that uses a QCView that has loaded a large and complex QTZ. This > >> set up has been running for quite a long time and the only significant > >> change is the content that the QTZ loads. We've been through the content > >> repeatedly to see if we can find a culprit but there is nothing > >> immediately obvious. > >> > >> Now, I know better than to expect anyone here to give me a solution, but I > >> thought if I posted a crash report someone might be able to suggest an > >> area I should be looking at. The below report tells me Thread 0 has > >> crashed whilst QCImageManager was optimising its caches, and I'm guessing > >> it's likely that a resource somewhere got over-released. So I know I need > >> to be careful about memory allocation. I'm fairly certain I have been in > >> the custom plugins that are loaded. I'm also aware that the app is loading > >> LOTS of content - object allocations during the load phase peak at about > >> 600MB so maybe I'm just being greedy? > >> > >> The 32 QCDatagramReceiver threads are not a surprise - I have 32 Network > >> Receiver patches somewhere deep in the QTZ. > >> > >> However, whats with the ~68 threads that are in QuickTimeH264.scalar and > >> AppleIntermediateCodec?! I don't have that many Movie Importers running at > >> the same time! I might have some sitting idle that sometimes get used to > >> load video, but not all at the same the time. Generally I'd only ever have > >> a maximum of two Movie Importers loading a video at the same time, and the > >> rest of the time the others would have their Movie Location set to blank > >> so they wouldn't have loaded any video. I know we use both H264 and AIC > >> for video content so this is a point of concern. > >> > >> So, does this suggest that QC isn't freeing resources (or killing old > >> threads...) used by Movie Importer? And is it plausible that this could be > >> pushing my app to a EXC_BAD_ACCESS? > >> > >> Sorry I can't post a QTZ demonstrating this in action, nor reduce the > >> project to reproduce the issue reliably. > >> > >> All suggestions welcome! Unless they involve phone hacking, please. > >> > >> Thanks, > >> > >> > >> Ade. > >> > >> > >> > >> > >> _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
