Did autorelease pools become no-ops? Look at this memory usage graph!

Question

Created Feb ’24

Replies 2

Boosts 0

Participants 2

Have an app in the store - 10K users. Using the same algorithm for years to download objects, convert them to ManagedObjects, then save them in a context.

Been using the exact same Objective-C code for over 5 years - no changes.

We build the app with Xcode 15.1, release it a few weeks ago, then slowly start getting reports of the app won't boot.

Run the app in 15.1, look at memory usage, and it's a flat line up. But the code is littered with autorelease statements. For this download, max memory was 2.3G! No wonder so many users crashing!

[Worked two weekends straight to get this fixed, but why did it happen???]

The last developer told me he added those to reduce memory pressure, and that they worked for him. (Unfortunately no old memory usage graphs).

But look at the attached image - memory usage increments in a straight line - no saw tooth where memory would get released.

Oh, and this is in one runloop on the main thread (don't blame me, I didn't write the original code!):

2.15.2.png

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’24

Autorelease pools have not become a no-op. Consider this snippet:

[NSThread detachNewThreadWithBlock:^{
    while (YES) {
        // @autoreleasepool {
            for (int i = 0; i < 10000; i++) {
                [[[NSObject alloc] init] autorelease];
            }
        // }
    }
}];

I used Xcode 15.2 to run this on my iOS 17.3.1 device, and the memory gauge grows without bound [1]. If I uncomment the @autoreleasepool statement then memory use stays flat.

As to what’s actually causing the problem you’re seeing, it’s hard to say without more info about what the app is doing. Are you able to reproduce this problem with a small test app?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Until it crashes with EXC_RESOURCE due to memory exhaustion a few seconds later.

0

Answer 2

dhoerl OP

Feb ’24

Quinn,

Well that was sort of ******-in-cheek! I didn't really think they had gone away, but perhaps behavior had changed. Our issue is just so bizarre.

In he end I pulled out an old Mac running Montery, loaded Xcode 14.2, and build the much older version of the app for which there had been no memory complaints.

When I build the above app, I got the same result!

So something in our backend objects increased the size - who knows what at the moment.

What confounded the issue is we had one complaint with the new app, then we started getting an avalanche of them - and we had (to our knowledge) not changed anything!

Murphy at it again!

David

0