I'm not sure this is an actual leak, it might be a false positive in the semantics that leaks is using to track memory. The GL Drivers are going to be heavily optimized (well, one hopes ;) ) and probably use tricky memory techniques that trigger false positives in the memory tracking in Leaks. Ive read about this before and recall it being mentioned a few times. My limited understanding is that the method used for tracking leaked memory is not 100% perfect and it can report false positives and also fail to report some actual leaks in certain circumstances. In other words, Leaks is not a panacea.
Running Leaks in instruments for 20 min on v002 Movie player demo composition playing a 1080p movie shows leaks of ~550k in gldFinish(), and up until the 15 minute mark QC kept allocating more memory climbing steadily until it reached around 120MB of ram (real). It looked like it had been leaking fairly consistently but once it reached 120MB QCs allocations seemed to taper off and remained consistent fluttering but never exceeding 122MB real. There did seem to be a leak in 10.6.3 reported on this exact issue for all GL applications (see http://lists.apple.com/archives/mac-opengl/2010/May/msg00034.html) however with no responses, and a bug fix reported in 10.6.4. So either the issue is back and real, and leaks is reporting this and all GL applications leak from the driver, or its a false positive. Watching closely in activity monitor seems to indicate that its a false positive, but ill keep leaks running for a few hours and see if indeed, it is leaking and its being masked by the QC caching and im not giving it long enough to really show. Curious either way. I'd love to hear some more expert opinions on this. On Dec 19, 2010, at 2:58 AM, Tamas Nagy wrote: > Just did a quick test with it, with 3rd party QC apps, seems all have > QCImageBuffer leaks(?). > > Also tested with v002 movie player, it leaks on my system, but it seems GL > driver related, see the screenshot: > http://dl.dropbox.com/u/2533/PastedGraphic-1.tiff > > > > On Dec 19, 2010, at 12:18 AM, vade wrote: > >> Also, are you using the latest beta v002 movie player? >> http://v002.info/downloads/beta/ ? Test with that as well, its 64 bit >> complaint and uses a background process to pass frames to the foreground UI >> app (similar to QTKitServer), and should not leak. >> >> >> On Dec 18, 2010, at 9:05 AM, Jens Barth wrote: >> >>> >>>>> our application uses a pbuffer to render a simple movie player >>>>> composition as an opengl texture. >>>> >>>> You should seriously consider using an FBO instead of a pbuffer. >>> >>> Thanks for the advice! We switched to FBO but the problem remains. >>> Furthermore I realized that memory leaks in -[QCImageBuffer(Extensions) >>> cacheRetain:] also >>> when loading the composition in a basic QCView. >>> >>>> Supplying some sample code in a radar would also be advisable. >>> What part would be necessary? >>> >>> >>> Best, >>> JB >>> _______________________________________________ >>> 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/doktorp%40mac.com >>> >>> This email sent to dokt...@mac.com >> >> _______________________________________________ >> 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/tamas.lov.nagy%40gmail.com >> >> This email sent to tamas.lov.n...@gmail.com >
_______________________________________________ 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
