crash - AutoreleasePoolPage

App & System Services Core OS
chetanp_9007 OP
Created Apr ’21
Replies 4
Boosts 0
Views 5.0k
Participants 4
I've got some crash reports which aren't easy to understand.
All the crashes happened when the application is in the background with multiple notifications received even without clicking on the notifications.
Crashes are related to the autorelease pool but don’t know the exact root cause. 


This is the stack:

Code Block 
OS Version:          iPhone OS 14.1 (18A8395)
Release Type:        User
Baseband Version:    2.01.05
Report Version:      104
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000020
VM Region Info: 0x20 is not in any region.  Bytes before following region: 4306190304
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                        100ab4000-100bd8000        [ 1168K] r-x/r-x SM=COW  ...rexendoMobile
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [1010]
Triggered by Thread:  0
Thread 0 name:
Thread 0 Crashed:
0   libobjc.A.dylib               	0x00000001bac3e160 objc_release + 16 (objc-runtime-new.h:1585)
1   libobjc.A.dylib               	0x00000001bac3f81c AutoreleasePoolPage::releaseUntil(objc_object**) + 204 (NSObject.mm:944)
2   libobjc.A.dylib               	0x00000001bac3f6e8 objc_autoreleasePoolPop + 212 (NSObject.mm:1211)
3   CoreFoundation                	0x00000001a6b3eae4 _CFAutoreleasePoolPop + 32 (NSObject.m:798)
4   CoreFoundation                	0x00000001a6aae480 __CFRunLoopPerCalloutARPEnd + 48 (CFRunLoop.c:762)
5   CoreFoundation                	0x00000001a6aa93f8 __CFRunLoopRun + 2576 (CFRunLoop.c:3120)
6   CoreFoundation                	0x00000001a6aa84bc CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
7   Foundation                    	0x00000001a7d29e30 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 232 (NSRunLoop.m:374)
8   CrexendoMobile                	0x0000000100bca5e4 -[MobilePortBinding performSynchronousOperation:] + 268 (MobileService.m:17547)
9   CrexendoMobile                	0x0000000100bcadf4 -[MobilePortBinding deviceExistsUsingParameters:] + 116 (MobileService.m:17638)
10  CrexendoMobile                	0x0000000100d7175c -[MobileServiceHelper deviceExists:error:] + 596 (MobileServiceHelper.m:612)
11  CrexendoMobile                	0x0000000100b43c34 -[CrexendoMobileAppDelegate applicationDidBecomeActiveBackgroundTasks:] + 1244 (CrexendoMobileAppDelegate.m:872)
12  Foundation                    	0x00000001a7e9424c __NSThreadPerformPerform + 188 (NSThread.m:807)
13  CoreFoundation                	0x00000001a6aaf81c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1967)
14  CoreFoundation                	0x00000001a6aaf718 __CFRunLoopDoSource0 + 208 (CFRunLoop.c:2011)
15  CoreFoundation                	0x00000001a6aaea94 __CFRunLoopDoSources0 + 376 (CFRunLoop.c:2056)
16  CoreFoundation                	0x00000001a6aa8d20 __CFRunLoopRun + 824 (CFRunLoop.c:2925)
17  CoreFoundation                	0x00000001a6aa84bc CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
18  GraphicsServices              	0x00000001bd5ba820 GSEventRunModal + 164 (GSEvent.c:2259)
19  UIKitCore                     	0x00000001a9455164 -[UIApplication _run] + 1072 (UIApplication.m:3270)
20  UIKitCore                     	0x00000001a945a840 UIApplicationMain + 168 (UIApplication.m:4739)
21  CrexendoMobile                	0x0000000100bdb60c main + 1209868 (main.m:21)
22  libdyld.dylib                 	0x00000001a676fe40 start + 4


Replies  4
Boosts  0
Views  5.0k
Participants  4
DTS Engineer OP
Apple
Apr ’21
Crashing coming out of the autorelease pool are usually the result of an over release. Consider this scenario:

  1. You allocate an object.

  2. You autorelease it.

  3. You then accidentally releases it.

  4. You return to the run loop.

  5. The autorelease pool cleans up.

  6. As part of this it releases the object again.

  7. That crashes because it’s releasing the object more times than it was retained.

Keep in mind that the source of this object isn’t necessarily your code. You may be looking at an OS bug here, or it may be a misunderstanding between you an the OS. For example, code like this could trigger the crash because cgImage was autoreleased by the UIKit.

Code Block  
UIImage * image = … whatever …;
CGImageRef cgImage = image.CGImage;
CFRelease(cgImage);


Over-release problems are hard to track down because they don’t always crash and, if they do, the crash is far removed from the original problem. The best way to flush them out is with the Zombies instrument.


Oh, and btw, what’s this about?

Code Block  
Thread 0 Crashed:
…
7   Foundation … -[NSRunLoop(NSRunLoop) runMode:beforeDate:] …


Running the runloop recursively on the main thread is always a concern. It’s only safe to do if:

  • You use a custom mode, and

  • You can guarantee that it won’t run too long (lest you be killed by the watchdog)

Is that the case here?

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

For a reference, I have just fixed a very similar crash. This was a Swift-only application, therefore no manual retain/release calls.

It turns out, one of my model classes had a deinit with some cleanup. That cleanup operation used a locking mechanism with a synchronous DispatchQueue. Of course, the block passed to the queue was referencing self strongly, thus calling retain from inside a deinit. When the clean up operation was completed, the self reference was released, thus calling a second deinit.

When you have an error like this, check your deinit first.

1
DTS Engineer OP
Apple
Sep ’21

I was just going to leave a comment but then I thought of something to say that was actually useful (-:

Of course, the block passed to the queue was referencing self strongly, thus calling -retain from inside a deinit.

This language should prevent you from doing stuff like this, and the Swift folks are in the process of tightening up the rules around that. See the Actor Initializers and Deinitializers thread, currently being discussed over on Swift Evolution.

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

0
goofyfooter OP
May ’22

Recursively adding an NSValue encoded object to a mutable array resulted in similar crashes in AutoreleasePoolPage.

Quinn's answer led me to solve my crash in AutoreleasePoolPage:

typedef struct {

    NSInteger       count;

    NSObject        *cellObject;

} CellDataStruct;

NSMutableArray *list = [NSMutableArray array];

CellData cellData;

    cellData.count = 47;

    cellData.cellObject = aCellObject;


// Recursively adding an NSValue encoded object to a mutable array causes crash in AutoreleasePoolPage:

    [list addObject: [NSValue value:&cellData withObjCType:@encode(CellDataStruct)]];

// Replacing with:

	[list addObject:aCellObject];

// prevents crash.
0
crash - AutoreleasePoolPage
First post date Last post date
 
 
Q