> On 05 Mar 2015, at 10:02, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Thursday March 05 2015 08:50:36 Sorvig Morten wrote: > >> This is exactly the use case I have in mind for 32-bit Qt. The tradeoff is >> the occasional memory leak when we get the ref-counting wrong. > > Reminds me of something. As I said, I used the 5.4.0 digia installer on OS X > 10.9 (a VM to be exact) and then copied the tree to 10.6.8 (which was then > still my main OS). Each and every application launched on 10.6 (64bit!) would > spew a series of warnings about leaking objects due to a missing autorelease > pool. That didn't happen on 10.9 . I've reported this. > > So not only may there be occasional places where you get ref-counting wrong, > there are also places where you don't do any at all. > > And if that doesn't raise warnings on 10.7+ that is probably because one way > or another ARC is used?
I think 10.7+ simply do not print the warnings, you can still see the leaks with a leak checker. The leaks are actually not due to incorrect ref counting, but instead due to missing autorelease pools (as the warning says). Autorelease pools can be put in place in two ways: 1) The native event loop will create one before calling out to Qt, and drain it when control returns. 2) User code may create (and drain) pools manually. The warnings we see from Qt applications typically happen on app startup, before the native event loop is started. While it is temping to add a top level long-lived pool somewhere this would not actually help, since the memory in that case would stay with the pool and not be released back to the system. The only solution we have so far (apart for simply living with the limited amount of startup leaks), is to add pools close to Cocoa API calls that may be made at app startup. And as it happens we just did that for leaks seen from Qt Creator: https://codereview.qt-project.org/#/c/107274/ (Qt 5.5) This makes Qt Creator startup leak free and should also help other apps, but there is no guarantee we’ve covered all cases. An application-level workaround could be to delay initialization and UI construction until after QApplication::exec() is called. Morten _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
