Memory leaks with autolayout enabled

Question

Created Jan ’18

Replies 3

Boosts 0

Views 2.4k

Participants 1

I changed my application which evolved through all ancient iOS versions up to iOS 11 now to finally use Autolayout. When i switch this on the memory consumption explodes and iOS reserves memory in 8.91 MB chunks until all available memory is consumed. This happens in the phases, where the application waits for URLSession Requests to complele, not while just being in the main loop and waiting for touches. Scrolling in the view also does not lead to any additional consumption, nor does any other interaction with it. The view in question has a toolbar and a scrollbar above it, which contains other simple views. So it is not too complex, and there were no memory issued up to now. The stack trace of the memory allocation in question always looks like this:

0 libsystem_kernel.dylib mach_vm_allocate

1 libsystem_kernel.dylib vm_allocate

2 QuartzCore CA::Render::Shmem::new_shmem(unsigned long)

3 QuartzCore CA::Render::Shmem::new_bitmap(unsigned int, unsigned int, unsigned int, unsigned int)

4 QuartzCore CABackingStorePrepareUpdates_(CABackingStore*, unsigned long, unsigned long, unsigned int, unsigned int, unsigned int, CA::GenericContext*, UpdateState*)

5 QuartzCore CABackingStoreUpdate_

6 QuartzCore invocation function for block in CA::Layer::display_()

7 QuartzCore x_blame_allocations

8 QuartzCore -[CALayer _display]

9 QuartzCore CA::Context::commit_transaction(CA::Transaction*)

10 QuartzCore CA::Transaction::commit()

11 QuartzCore CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*)

12 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__

13 CoreFoundation __CFRunLoopDoObservers

14 CoreFoundation __CFRunLoopRun

15 CoreFoundation CFRunLoopRunSpecific

16 GraphicsServices GSEventRunModal

17 UIKit UIApplicationMain

18 MyApp main /Users/Me/Documents/Dokumente - main.m:14

19 libdyld.dylib start

When i turn off autolayout for this view memory leaking stops, and everything works well again (but without a porper layout of the screen of course :-/). Did you have similar experiences when migrating to autolayout how can i pin down the main cause of this issue?

Boost

Answer 1

helmutnn OP

Jan ’18

Ok, first hint found: The app changes two text attribues (UILables) from a callback of the URL Session. As soon as i remove these lines, everything works smooth again. So it might be an issue of from which thread out these attributes are changed. As i want to inform the user about the progress of the requests, the question arises at me about how to set these Lables correctly to avoid making autolayout run wild on memory consumption? Any ideas?

0

Answer 2

helmutnn OP

Jan ’18

The URLSession callbacks arrive on the main thread (0). I suppose it should not be an issue to change UILabel contents from within this thread, or am i wrong here?

0

Answer 3

helmutnn OP

Jan ’18

Accepted Answer

The reason for the memory leak was in ViewDidLayoutSubviews. A slight leak in this method can have enormous potential when enabling AutoLayout, because ViewDidLayoutSubviews is called much more often then. I worked around the leak in this method and the problem is solved.

1