On Thursday March 05 2015 12:15:39 Sorvig Morten wrote: >The leaks are actually not due to incorrect ref counting, but instead due to >missing autorelease pools (as the warning says).
Of course. That's what I actually meant when writing "not doing any refcounting at all". My bad. >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: Yep. That *is* the only solution AFAIK, if there's no event loop in place, and one that in principle can always be used (even if you do have an event loop, e.g. to release a big, temporary chunk of memory if you're sure that's safe to do). >This makes Qt Creator startup leak free and should also help other apps, but >there is no guarantee we’ve covered all cases. Yes, annoyingly the warning message never identified the object being leaked (and setting a breakpoint wasn't always feasible either IIRC). Not having any messages at all makes it even more difficult to hunt down all cases. >An application-level workaround could be to delay initialization and UI >construction until after QApplication::exec() is called. Does this really only concern UI initialisation and construction, or are there other things that are done in ObjC that could be used by applications that do not use QApplication? (qstandardpaths_mac.mm is ObjC++ and is likely to be called by KF5 applications that don't use QApplication.) René _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
