My application creates instances of a custom subclass of UIView and adds those instances placed horizontally adjacent to each other. When a new instance of my UIView class is created, I can add it to the UIScrollView and reset the contentsize. I then call
[UIScrollView setContentOffset:(some point) animated:NO].
This works just fine.
The issue is when I call the above mentioned method with animation, i.e.
[UIScrollView setContentOffset:(some point) animated:YES]
, the application crashes.
The call stack looks like this:
> #0 0x3145b870 in ___forwarding___ ()
> #1 0x313b6650 in _CF_forwarding_prep_0 ()
> #2 0x317d84a2 in -[UIAnimator stopAnimation:] ()
> #3 0x317d84a2 in -[UIAnimator stopAnimation:] ()
> #4 0x317d7f0e in -[UIAnimator(Static) _advance:withTimestamp:] ()
> #5 0x317d7e00 in -[UIAnimator(Static) _LCDHeartbeatCallback:] ()
> #6 0x3531d86e in CA::Display::DisplayLink::dispatch(unsigned long long, unsigned long long) ()
> #7 0x3531d7c4 in CA::Display::IOMFBDisplayLink::callback(__IOMobileFramebuffer*,
> unsigned long long, unsigned long long, unsigned long long, void*) ()
> #8 0x33a56000 in IOMobileFramebufferVsyncNotifyFunc ()
> #9 0x36e3c60c in IODispatchCalloutFromCFMessage ()
> #10 0x31422f12 in __CFMachPortPerform ()
> #11 0x3142d522 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
> #12 0x3142d4c4 in __CFRunLoopDoSource1 ()
> #13 0x3142c312 in __CFRunLoopRun ()
> #14 0x313af4a4 in CFRunLoopRunSpecific ()
> #15 0x313af36c in CFRunLoopRunInMode ()
> #16 0x32888438 in GSEventRunModal ()
> #17 0x316b4cd4 in UIApplicationMain ()
When I enable Zombies, the application output produces:
*** -[__NSArrayM removeObject:]: message sent to deallocated instance 0x113dbb10
Additional Info: UIScrollView's delegate is never set. I am using ARC.
I found my issue.
I was calling the method that called setContentOffset from a background thread.
BackgroundThread --> My random processing method --> Setup new UIView and add it to UIScrollView --> Call setContentOffset with animations
The above flow causes the crash. When I called the same processing method from the main thread, it worked just fine.
Apparently iOS does not like animations called from a background thread.
One of the views in the scrollView is getting released. Probably you "jump" over it when you turn animation off - when its on, the system tries to get a series of "snapshots" of the changes, and when it tries to access the one view boom down you go. So you can enable Zombies and find out exactly what type of object is getting the message, and in the debugger you can probably "po" that object.
Another way to do it would be to write our own test animation, move the contentOffset say 20 pixels at a time in a loop with no animation, and watch to see when it crashes (it surely will)!
Related
I'm getting a crash from GCDWebServer (3.3.3) when my app enters the background:
#3 0x000000010041ea80 in -[GCDWebServer dealloc] at project/Pods/GCDWebServer/GCDWebServer/Core/GCDWebServer.m:221
#4 0x00000001004248b8 in __destroy_helper_block_ ()
#5 0x000000018dd52a28 in _Block_release ()
#6 0x00000001020ad21c in _dispatch_client_callout ()
#7 0x00000001020b2284 in _dispatch_main_queue_callback_4CF ()
#8 0x000000018ee21f2c in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#9 0x000000018ee1fb18 in __CFRunLoopRun ()
#10 0x000000018ed4e048 in CFRunLoopRunSpecific ()
#11 0x00000001907d1198 in GSEventRunModal ()
#12 0x0000000194d28628 in -[UIApplication _run] ()
#13 0x0000000194d23360 in UIApplicationMain ()
#14 0x000000010009243c in main at project/main.m:10
#15 0x000000018dd305b8 in start ()
Enqueued from com.apple.main-thread (Thread 1)Queue : com.apple.main-thread (serial)
#0 0x00000001020b8ba4 in _dispatch_queue_push ()
#1 0x0000000100424680 in -[GCDWebServer _stop] at project/Pods/GCDWebServer/GCDWebServer/Core/GCDWebServer.m:734
#2 0x0000000100424a10 in -[GCDWebServer _didEnterBackground:] at project/Pods/GCDWebServer/GCDWebServer/Core/GCDWebServer.m:746
The specific line is:
GWS_DCHECK(_options == nil); // The server can never be dealloc'ed while running because of the retain-cycle with the dispatch source
It looks like the _options dictionary has to be nil (eg. the server has to be stopped) but it looks like the _options is never set to nil on this code path: it's set to nil in - stop but not in - _stop.
I'm probably missing something as this would have been noticed by other people.
I had the same problem. I solved it saving the server in a static variable on my class instead of saving in a function.
It doesn't works:
class Server {
static func initialize() {
let webServer = GCDWebServer()
...
webServer?.start(withPort: 8081, bonjourName: nil)
}
}
It's works:
class Server {
static let webServer = GCDWebServer()
static func initialize() {
...
webServer?.start(withPort: 8081, bonjourName: nil)
}
}
I'm struggling with a pdf export method that's was running just fine until I ported the app to the arm64 achitecture.
Bacisally, the method opens an existing PDF, it creates a new pdf file, and draws the content of the first pdf into the newly created one before adding more content pages.
When the method tries to create a new pdf page to the document (after the first pdf was integrated to the new pdf) the app crashes with a EXC_BAD_ACCESS warning on UIGraphicsBeginPDFPage(); call .
It only happens with some PDF files, not all and only on 64 bit devices.
Here's the stacktrace which shows the CGPDFSecurityManagerCreateDecryptor () call which I couldn't find what it does.
Thread 14Queue : NSOperationQueue 0x14f6dd3a0 :: NSOperation 0x17504a470 (serial)
#0 0x00000001838aeee4 in CGPDFSecurityManagerCreateDecryptor ()
#1 0x00000001838d1004 in pdf_filter_chain_create ()
#2 0x0000000183831e00 in CGPDFStreamCreateFilterChain ()
#3 0x000000018383226c in chain_get_bytes ()
#4 0x0000000183b5e0ac in unpackImageRow ()
#5 0x0000000183b5dfd4 in PDFImageEmitData ()
#6 0x0000000183b5f684 in emit_image ()
#7 0x0000000183b5ef9c in PDFImageEmitDefinition ()
#8 0x0000000183464584 in __CFSetApplyFunction_block_invoke ()
#9 0x00000001834643bc in CFBasicHashApply ()
#10 0x00000001834642e4 in CFSetApplyFunction ()
#11 0x0000000183b5fa9c in PDFImageSetEmitDefinitions ()
#12 0x0000000183b590c0 in emit_page_resources(PDFDocument*) ()
#13 0x0000000183b5904c in PDFDocumentEndPage ()
#14 0x0000000183b57cf0 in pdf_EndPage ()
#15 0x0000000187fda904 in UIGraphicsBeginPDFPageWithInfo ()
#16 0x00000001002093e8 in -[ExportTools renderPdfContentToContext:forPlanVersion:]
#17 0x00000001001fba60 in -[ExportTools generatePdfReportWithOptions:]
#18 0x00000001000f7eb4 in -[DetailViewController generatePdfAndShowModalOpenWithAppWithOptions:]
#19 0x00000001835883c0 in __invoking___ ()
#20 0x0000000183486138 in -[NSInvocation invoke] ()
#21 0x000000018443ba20 in -[NSInvocationOperation main] ()
#22 0x000000018437c61c in -[__NSOperationInternal _start:] ()
#23 0x000000018443e26c in __NSOQSchedule_f ()
#24 0x000000010105cdf0 in _dispatch_client_callout ()
#25 0x0000000101067854 in _dispatch_queue_drain ()
#26 0x0000000101060120 in _dispatch_queue_invoke ()
#27 0x000000010106975c in _dispatch_root_queue_drain ()
#28 0x000000010106af18 in _dispatch_worker_thread3 ()
#29 0x00000001945012e4 in _pthread_wqthread ()
If you have any idea about this crash, your help would be greatly appreciated, been one day trying everything to fix this and beggening to wonder if it's not a UIKit bug...
Thanks
I had a crash on the CGPDFSecurityManagerCreateDecryptor method on 64-devices only with the following code:
CGPDFDocumentRelease(pdf);
CGDataProviderRelease(provider);
UIGraphicsEndPDFContext();
CGPDFSecurityManagerCreateDecryptor would get called when ending the context. The crash went away when I ended the context BEFORE releasing the document and provider.
UIGraphicsEndPDFContext();
CGPDFDocumentRelease(pdf);
CGDataProviderRelease(provider);
I've been struggling with this same issue too, and while Bill's answer gave me the clue I had to do it a little bit differently. In my situation there are a variable number of source PDFs that get copied into the target PDF so I can't just simply move UIGraphicsEndContext before CGPDFDocumentRelease. The code structure looks roughly like this:
UIGraphicsBeginPDFContextToFile(...);
// ...
for each attachment pdf {
srcPdf = CGPDFDocumentCreateWithURL(...); // open source PDF
// ...
UIGraphicsBeginPDFPageWithInfo(...); // new page in target PDF, this randomly crashes
// ...
CGPDFDocumentRelease(srcPdf); // close source PDF
}
// ...
UIGraphicsEndPDFContext();
So instead I tried capturing the references to all the source PDFs it used and releasing them all after the rest of the target PDF is done, much later in the code. This is a kind of ugly because it moves the responsibility far away and holds all the memory until the end instead of releasing after each one is rendered... BUT it does appear to work! It's hard to say definitively since it's been a random crash but I haven't seen it since and I've been hammering it a lot trying to get it reoccur.
pdfRefs = [[NSPointerArray alloc] init];
UIGraphicsBeginPDFContextToFile(...);
// ...
for each attachment pdf {
srcPdf = CGPDFDocumentCreateWithURL(...); // open source PDF
// ...
UIGraphicsBeginPDFPageWithInfo(...); // new page in target PDF, this randomly crashes
// ...
[pdfRefs addPointer:srcPdf]; // store for later closing
}
// ...
UIGraphicsEndPDFContext();
for each srcPdf in pdfRefs {
CGPDFDocumentRelease(srcPdf); // close it here
}
I've been struggling with a strange problem for two days now. I went through every related question on SO but none solved the issue. I'm working on Xcode5. I'm using ARC and CoreData.
On iOS7 (simulator):
`[CFString release]: message sent to deallocated instance`
Thread 1, Queue : com.apple.main-thread
0 0x03c7d3ba in __kill ()
1 0x03c7c4b8 in kill$UNIX2003 ()
2 0x0347a921 in ___forwarding___ ()
3 0x0347a4ee in _CF_forwarding_prep_0 ()
4 0x02b7b002 in -[NSConcreteAttributedString dealloc] ()
5 0x02f66692 in objc_object::sidetable_release(bool) ()
6 0x02f65e81 in objc_release ()
7 0x02f66ce7 in (anonymous namespace)::AutoreleasePoolPage::pop(void*) ()
8 0x00739bc4 in CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) ()
9 0x0345253e in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
10 0x0345248f in __CFRunLoopDoObservers ()
11 0x034303b4 in __CFRunLoopRun ()
12 0x0342fb33 in CFRunLoopRunSpecific ()
13 0x0342f94b in CFRunLoopRunInMode ()
14 0x04bd19d7 in GSEventRunModal ()
15 0x04bd17fe in GSEventRun ()
16 0x0196794b in UIApplicationMain ()
17 0x0000262d in main
The Zombies Instruments point to the second line where I set the cell's text labels:
cell.txtLabel.text = _reservationModule.newReservationText;
cell.subtitleTxtLabel.text = _reservationModule.newReservationSubtitle;
_reservationModule is a Core Data entity featuring the string properties. It's defined in the view controller as #property (nonatomic, strong) ReservationModule *reservationModule;
The Zombie history:
Event Type ∆ RefCt RefCt Timestamp Responsible Library Responsible Caller
Malloc/Retain/Release (4) 01:01.114.922 CoreData _prepareResultsFromResultSet
0 Malloc +1 1 01:01.114.922 CoreData _prepareResultsFromResultSet
1 Retain +1 2 01:01.116.184 CoreData -[_CDSnapshot mutableCopy]
2 Release -1 1 01:01.318.588 MyApp -[ReservationModuleChoice2ViewController configureSubtitleImageTableViewCell:atIndexPath:]
3 Release -1 0 01:05.004.359 CoreData -[_CDSnapshot dealloc]
4 Zombie -1 01:07.441.465 CoreData -[_CDSnapshot dealloc]
They've never occurred on Xcode 4.6.x though.
Any help is highly appreciated!
Thanks!
The answer is trivial and hasn't anything to do with retain counters...
I oversaw that it isn't allowed to name variables/properties starting with new with ARC enabled. This obviously resulted in an over release thus generating the error...
From Apple documentation: https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/introduction/introduction.html
To allow interoperation with manual retain-release code, ARC imposes a
constraint on method naming:
You cannot give an accessor a name that begins with new. This in turn
means that you can’t, for example, declare a property whose name
begins with new unless you specify a different getter
My app uses core data for data storage, and I added code that handles cases where the database/model is not compatible/corrupt/etc. In this case, I will present an error message, prompting the user to wipe all of the data, and restart the app, so the user can start again from scratch.
The problem is, that the app will crash after the storage was deleted and the user pressed the homebutton. My wipe code looks like this:
// destroy context
if ([__managedObjectContext hasChanges])
[__managedObjectContext rollback];
[__managedObjectContext release];
__managedObjectContext = nil;
// remove store
if (__persistentStoreCoordinator.persistentStores.count)
[__persistentStoreCoordinator removePersistentStore:[__persistentStoreCoordinator persistentStoreForURL:localURL] error:nil];
NSLog(#"retain count: %p %d", __persistentStoreCoordinator, __persistentStoreCoordinator.retainCount);
[__persistentStoreCoordinator release];
__persistentStoreCoordinator = nil;
Interestingly the retain count of the NSPersistentStoreCoordinator is 1, therefore the release above will dealloc the object.
When the user now presses the homebutton, I will get this in the console:
*** -[NSPersistentStoreCoordinator retain]: message sent to deallocated instance 0x8345530
The printed address 0x8345530 in this example is equal to the NSPersistentStoreCoordinator object released in the above code. The backtrace looks like this:
(gdb) bt
#0 0x0178be1e in ___forwarding___ ()
#1 0x0178bce2 in __forwarding_prep_0___ ()
#2 0x0122c75e in -[_NSSQLCoreConnectionObsever _purgeCaches:] ()
#3 0x00345a39 in __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 ()
#4 0x017f0885 in ___CFXNotificationPost_block_invoke_0 ()
#5 0x017f07a8 in _CFXNotificationPost ()
#6 0x0028a1aa in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#7 0x005e6169 in -[UIApplication _handleApplicationSuspend:eventInfo:] ()
#8 0x005ee8bd in -[UIApplication handleEvent:withNewEvent:] ()
#9 0x005ef1f8 in -[UIApplication sendEvent:] ()
#10 0x005e2aa9 in _UIApplicationHandleEvent ()
#11 0x01e45fa9 in PurpleEventCallback ()
#12 0x017f91c5 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#13 0x0175e022 in __CFRunLoopDoSource1 ()
#14 0x0175c90a in __CFRunLoopRun ()
#15 0x0175bdb4 in CFRunLoopRunSpecific ()
#16 0x0175bccb in CFRunLoopRunInMode ()
#17 0x01e44879 in GSEventRunModal ()
#18 0x01e4493e in GSEventRun ()
#19 0x005e0a9b in UIApplicationMain ()
#20 0x000046fd in main (argc=1, argv=0xbffff63c) at main.m:24
After a complete restart the app will of course work just fine again, with a plain new and empty storage file.
The above code is from my app delegate subclass, and the properties are declared like this:
#property (readonly, strong, nonatomic) NSManagedObjectContext *managedObjectContext;
#property (readonly, strong, nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator;
#synthesize managedObjectContext = __managedObjectContext;
#synthesize persistentStoreCoordinator = __persistentStoreCoordinator;
What I just dont understand is, how can any object still use the OLD store coordinator instance when the retaincount obviously reached zero? I don't ever use/access this object outside of the app delegate class.
[edit] Just ran instruments (Zombie-mode), which yields similar results:
http://i41.tinypic.com/317ci91.jpg
As can be seen from the backtrace already, some purge-caches method is causing the crash. What is it, and how can I make it use the NEW store coordinator instance, and not the zombie one?
have you tried [self saveContext]; and place it in applicationWillTerminate: before the app has terminated. And you shouldn't use retainCount to see if an object is overreleased or overretain. You should user instrument instead
I find my self out of ideas trying to get this app to work. My app uses a split view to show to lists. the "Master" list should hold a list of the user's Facebook friends. Since the app does not force you to login, if you're not logged in yet it shows "You have no friends" in the list till you've logged in. My problem is that once I've loaded all the friends and call [self.tableView reloadData] my program crashes some in there, and despite my best attempts at debugging it I can't find it. The method is
- (void)request:(FBRequest *)request didLoad:(id)result
{
if ([result isKindOfClass:[NSArray class]] && ([result count] > 0)) {
result = [result objectAtIndex:0];
}
switch (((Facebook *)[Facebook shared]).currentCall) {
case graphUserFriends:
{
_friends = [NSMutableArray array];
NSArray *resultData = [result objectForKey:#"data"];
if ([resultData count] > 0)
{
for (NSUInteger i=0; i<[resultData count] && i < 25; i++)
{
NSDictionary *friendDictionary = [resultData objectAtIndex:i];
FbFriend * f = [[[FbFriend alloc] initWithName:[friendDictionary objectForKey:#"name"] Id:[friendDictionary objectForKey:#"id"]] autorelease];
[_friends addObject:f];
}
}
[self.tableView reloadData];
break;
}
default:
break;
}
}
The whole source code (and Xcode 4 project) can be downloaded from https://skydrive.live.com/redir.aspx?cid=04b38cdd7b38bb7f&resid=4B38CDD7B38BB7F!798&parid=4B38CDD7B38BB7F!470&authkey=!API4iVva95nZFL8
Console (At Crash):
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug 15 16:03:10 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 48870.
Catchpoint 3 (throw)Pending breakpoint 1 - "objc_exception_throw" resolved
Current language: auto; currently objective-c
(gdb) bt
#0 0x0156ecf0 in objc_exception_throw ()
#1 0x013c9674 in -[__NSArrayI objectAtIndex:] ()
#2 0x00454805 in -[UITableViewDataSource tableView:heightForRowAtIndexPath:] ()
#3 0x0026427a in -[UITableViewController tableView:heightForRowAtIndexPath:] ()
#4 0x0020f548 in -[UISectionRowData refreshWithSection:tableView:tableViewRowData:] ()
#5 0x00211722 in -[UITableViewRowData numberOfRows] ()
#6 0x000c17c7 in -[UITableView noteNumberOfRowsChanged] ()
#7 0x000c12c1 in -[UITableView reloadData] ()
#8 0x0000247e in -[MasterViewController request:didLoad:] (self=0x6a491e0, _cmd=0x12e65, request=0x681e930, result=0x6824250) at /Users/CheckM8/Documents/Xcode 4/Projects/iPeople4/iPeople4/MasterViewController.m:46
#9 0x00009d36 in -[FBRequest handleResponseData:] (self=0x681e930, _cmd=0x1397a, data=0x6a76c60) at /Users/CheckM8/Documents/Xcode 4/facebook-facebook-ios-sdk-74358cd/src/FBRequest.m:261
#10 0x0000a357 in -[FBRequest connectionDidFinishLoading:] (self=0x681e930, _cmd=0xade62e, connection=0x681ec40) at /Users/CheckM8/Documents/Xcode 4/facebook-facebook-ios-sdk-74358cd/src/FBRequest.m:346
#11 0x00a29a59 in ___NSURLConnectionDidFinishLoading_block_invoke_0 ()
#12 0x00a27e94 in __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 ()
#13 0x00a28eb7 in -[NSURLConnectionInternalConnection invokeForDelegate:] ()
#14 0x00a27e4f in -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] ()
#15 0x00a27fd5 in -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] ()
#16 0x0096cf6a in _NSURLConnectionDidFinishLoading ()
#17 0x0398fbbd in URLConnectionClient::_clientDidFinishLoading ()
#18 0x03a5c5ea in URLConnectionClient::ClientConnectionEventQueue::processAllEventsAndConsumePayload ()
#19 0x03986298 in URLConnectionClient::processEvents ()
#20 0x03a5c16b in non-virtual thunk to URLConnectionInstanceData::multiplexerClientPerform() ()
#21 0x03986137 in MultiplexerSource::perform ()
#22 0x013b197f in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#23 0x01314b73 in __CFRunLoopDoSources0 ()
#24 0x01314454 in __CFRunLoopRun ()
#25 0x01313db4 in CFRunLoopRunSpecific ()
#26 0x01313ccb in CFRunLoopRunInMode ()
#27 0x012c6879 in GSEventRunModal ()
#28 0x012c693e in GSEventRun ()
#29 0x00034a9b in UIApplicationMain ()
#30 0x00001d82 in main (argc=1, argv=0xbfffed64) at /Users/CheckM8/Documents/Xcode 4/Projects/iPeople4/iPeople4/main.m:16
#31 0x00001cf5 in start ()
You've made the classic memory management mistake: You're directly accessing your ivars and it burned you.
_friends = [NSMutableArray array];
This is an under-retain (which will crash later), and also a possible leak if _friends had a prior value. You should always use accessors for your ivars except in dealloc and init:
self.friends = [NSMutableArray array];
...
[self.friends addObject:f];
EDIT: From your stacktrace, your bug is in your table view data source's tableView:heightForRowAtIndexPath:. It looks like you're reading off the end of your array.