I'm getting the following EXC_BAD_INSTRUCTION exception when opening a window in Lion but the app appears to work fine in Mountain Lion. What can be the problem?
Process: MyApp [595]
Path: /Users/USER/Desktop/MyApp.app/Contents/MacOS/MyApp
Identifier: com.example.MyApp
Version: ??? (0.4)
Code Type: X86-64 (Native)
Parent Process: launchd [146]
Date/Time: 2012-09-25 11:09:14.498 +0200
OS Version: Mac OS X 10.7.3 (11D50d)
Report Version: 9
Sleep/Wake UUID: BA4DA964-60E8-4DC6-B63C-99435074A41C
Interval Since Last Report: 2901634 sec
Crashes Since Last Report: 367
Per-App Interval Since Last Report: 129923 sec
Per-App Crashes Since Last Report: 8
Anonymous UUID: BFF6E121-730D-4729-B07F-DA8550F46E14
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Application Specific Information:
objc[595]: garbage collection is OFF
objc[595]: cannot form weak reference to instance (0x7fc091666650) of class MyViewController
Performing #selector(startPressed:) from sender NSButton 0x7fc09167d210
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff91496768 _objc_trap + 4
1 libobjc.A.dylib 0x00007fff914968aa _objc_fatal + 195
2 libobjc.A.dylib 0x00007fff914a24ad weak_register_no_lock + 346
3 libobjc.A.dylib 0x00007fff914a2a59 objc_storeWeak + 360
4 com.apple.CoreFoundation 0x00007fff8f29c75d -[NSObject performSelector:withObject:] + 61
5 com.apple.AppKit 0x00007fff94bb5392 -[NSNibOutletConnector establishConnection] + 405
6 com.apple.AppKit 0x00007fff94bb2a89 -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 107
Found it. The problem was that I had declared a delegate id property with weak and assigned a NSVieWcontroller to it.
Apparently, if you want to support Lion and be safe you should never declare id properties as weak. From the Transitioning to ARC Release Notes:
Note: In addition, in OS X v10.7, you cannot create weak references to
instances of NSFontManager, NSFontPanel, NSImage, NSTableCellView,
NSViewController, NSWindow, and NSWindowController. In addition, in OS
X v10.7 no classes in the AV Foundation framework support weak
references.
Solution: use assign instead.
#property (nonatomic, assign) IBOutlet id<MyDelegateProtocol> delegate;
Related
I am having truble while using [UIImage imageNamed:] method
It appeares that crash occured when launching app from killed state and getting an resource image.
All my images are stored in bundle and no issue with background thread.
Following is crash log
Thread : Crashed: com.apple.main-thread
19 UIKit 0x186739714 +[UIImage imageNamed:inBundle:compatibleWithTraitCollection:] + 380
20 UIKit 0x18658cc8c +[UIImage imageNamed:] + 124
This happens on
UIImage * image = [UIImage imageNamed:#"abc.png"];
I am making a simple mac os x app, in which I will be showing some records in a table view, after retrieving those from local db. I am using core data and NSArrayController proxy for the same and I am trying to achieve it through cocoa-bindings.
Now I can easily make it working, by performing this binding in NSArrayController proxy:
Proxy: NSArrayController
Parameters: Managed Object Context
Bind to: App Delegate
Model Key Path: self.managedObjectContext
but I am trying to use NSManagedObjectContext proxy from Interface builder library, for this binding:
Proxy: NSArrayController
Parameters: Managed Object Context
Bind to: Managed Object Context
Model Key Path: self
I am surprised that there is no binding available for it, in bindings pan. At least there should be a binding to map persistent store coordinator to it.
To assign MOC a persistent store coordinator, I am using below code:
#property (strong) IBOutlet NSManagedObjectContext *listManagedObjectContext;
[self.listManagedObjectContext setPersistentStoreCoordinator:[NSAppDelegate persistentStoreCoordinator]];
Problem is -
I am continuously getting this message in console:
Cannot perform operation since managed object context has no
persistent store coordinator
With this stack backtrace:
0 CoreFoundation 0x00007fff8b59fb06 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff881103f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8b59f8dc +[NSException raise:format:] + 204
3 AppKit 0x00007fff907eb5e6 -[_NSManagedProxy _persistentStoreCoordinator] + 81
4 AppKit 0x00007fff907eb528 -[_NSManagedProxy _entity] + 49
5 AppKit 0x00007fff907eb43a -[_NSManagedProxy fetchRequestWithSortDescriptors:limit:] + 95
6 AppKit 0x00007fff90cc04f0 -[NSObjectController(NSManagedController) _executeFetch:didCommitSuccessfully:actionSender:] + 73
My questions are -
What is the correct way of using NSManagedObjectContext proxy in interface builder library?
How can I resolve observed problem?
Please suggest.
Resolved this problem, by using this code:
- (void)awakeFromNib
{
[self.listManagedObjectContext setPersistentStoreCoordinator:[NSAppDelegate persistentStoreCoordinator]];
}
I am trying to get my app to run on version 10.6 but when I do I get an EXC_BAD_ACCESS exception. When I run it on my computer which has the latest version it runs fine, but for some reason it won't work on versions below 7. Since I don't develop on a 10.6 computer all I have to look at is the crash log:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff87604930 CFDictionaryGetValue + 96
1 com.apple.CFNetwork 0x00007fff810814d9 CFHTTPCookieCreateWithProperties + 111
2 com.apple.Foundation 0x00007fff88812f4c -[NSHTTPCookie initWithProperties:] + 29
3 com.apple.Foundation 0x00007fff88813243 +[NSHTTPCookie cookieWithProperties:] + 50
This is the main part of the crash log. It seems to crash trying to get a dictionary value but I'm not exactly sure how to read these.
Okay I was able to solve it. I loaded a cookie on start with a method like this:
- (NSHTTPCookie *)loadCookie {
NSDictionary *properties = [[NSUserDefaults standardUserDefaults] dictionaryForKey:kDefCookie];
return [NSHTTPCookie cookieWithProperties:properties[COOKIE_KEY]];
}
I saved the cookie properties in defaults so I could save the users cookie across sessions. Running on the latest version, this method returned nil for me when there was no cookie stored in defaults. For some reason this doesn't seem to work on 10.6. I changed the method like this and it works perfectly now.
- (NSHTTPCookie *)loadCookie {
NSDictionary *properties = [[NSUserDefaults standardUserDefaults] dictionaryForKey:kDefCookie];
if (properties)
return [NSHTTPCookie cookieWithProperties:properties[COOKIE_KEY]];
else return nil;
}
Thanks Carter Pape fo helping me read the crash log. I focused to much on the cfDictionary part and I didn't read the stuff that came before
We are developing an iPad application starting from map view with annotations.
By using storyboard when We switch to another view which has an opengl based charting solution (shinobi).
On return to the view with map it has no problem until a touch on the map to move it.
As we try to move map it crashes with exc_bad_access exception at [EAGLContext setCurrentContext]
Any ideas?
Here is the part of the crash log:
OS Version: iOS 6.0 (10A403)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000c
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 OpenGLES 0x39974b12 +[EAGLContext setCurrentContext:] + 74
1 VectorKit 0x32c64f0c -[VGLGPU setPaused:] + 120
2 VectorKit 0x32c54db8 -[VKMainLoop updateLinkState] + 492
3 VectorKit 0x32c54950 -[VKScreenCanvas _updateDisplayStatus:] + 104
4 VectorKit 0x32ccea9a -[VKScreenCanvas setGesturing:] + 254
5 MapKit 0x34defc3c -[MKMapView _willStartUserInteraction] + 48
6 MapKit 0x34de891a -[MKMapGestureController beginGesturing] + 50
7 MapKit 0x34de8c6c -[MKMapGestureController handlePan:] + 252
8 UIKit 0x379ead2c _UIGestureRecognizerSendActions + 124
9 UIKit 0x379b23d8 -[UIGestureRecognizer _updateGestureWithEvent:] + 388
10 UIKit 0x37b9f474 ...
I work for Shinobi and we've been investigating this - it's partly due to Apple's map code keeping hold of our GL-Context. As a temporary workaround, you can create a subclass of a ShinobiChart and nil-out the GL context in the chart's dealloc method, like so:
- (void) dealloc {
[super dealloc];
[EAGLContext setCurrentContext:nil]; // must be after dealloc
}
or if you're using ARC, (since sending dealloc is not allowed):
#import <ShinobiCharts/SChartCanvas.h>
#interface ShinobiChartGl : ShinobiChart
#end
#implementation ShinobiChartGl
- (void) dealloc
{
[self.canvas.glView removeFromSuperview];
self.canvas.glView = nil; // force glView dealloc
[EAGLContext setCurrentContext:nil];
}
#end
Hope this helps, but do contact us directly - we'll have a full fix out in our next release.
for those who did not work even tried [EAGLContext setCurrentContext:nil]; on dealloc, try this
dispatch_async(dispatch_get_main_queue(), ^{
[EAGLContext setCurrentContext:nil];
});
EAGLContext should be set on main thread.
My app is crashing on Lion when it awakes from sleep.
The problem seems to be with a background thread that is looking for weather info.
I'm not sure but I think the crash log is telling me that the autorelease pool is popping objects that are no longer there, can someone help me confirm this?
Here is the relevant details for the Crash log:
Process: myApp [14187] Identifier: myApp Version:
??? (???) Code Type: X86-64 (Native) Parent Process: launchd
[224]
Date/Time: 2011-08-24 18:58:00.581 -0400 OS Version: Mac OS
X 10.7.1 (11B26) Report Version: 9
Crashed Thread: 7
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes:
KERN_INVALID_ADDRESS at 0x0000000000000010
Application Specific Information: objc[14187]: garbage collection is
OFF
Thread 7 Crashed: 0 libobjc.A.dylib
0x00007fff9321700b (anonymous
namespace)::AutoreleasePoolPage::pop(void*) + 385 1
com.apple.CoreFoundation 0x00007fff961306a5
CFAutoreleasePoolPop + 37 2 com.apple.Foundation
0x00007fff969350d7 -[NSAutoreleasePool drain] + 154 3
com.piso13.opusDomini 0x00000001000acb91 -[Weather
internalStart] + 417 4 com.apple.Foundation
0x00007fff9698b1ea -[NSThread main] + 68 5 com.apple.Foundation
0x00007fff9698b162 NSThread_main + 1575 6 libsystem_c.dylib
0x00007fff90b068bf _pthread_start + 335 7 libsystem_c.dylib
0x00007fff90b09b75 thread_start + 13
Here is my code for Weather Internal Start:
-(void)internalStart{
pool = [[NSAutoreleasePool alloc] init];
forecast = FALSE;
liveweather = FALSE;
NSString *query = [self generateQuery];
if (query == nil) {
[pool drain];
return;
}
XmlWrapper * xmlWrapper = [[XmlWrapper alloc] initWithQuery:query delegate:self name:#"liveweather"];
[xmlWrapper release];
query = [self generateForecastQuery];
xmlWrapper = [[XmlWrapper alloc] initWithQuery:query delegate:self name:#"forecast"];
[xmlWrapper release];
[pool drain];
}
Should I even be calling [pool drain] ?
create your autorelease pools with bound lifetimes and explicit scopes.
in this case, you store your autorelease pool in an ivar (presumed).
just make it local to the method, like so:
- (void)internalStart
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
//...
[pool drain], pool = nil;
}
the problems that are typically introduced are:
1) autorelease pools are stack based (pools are pushed and popped). by holding onto it, you can easily mess up the stack order.
2) if this class operates in a multithreaded context, you can easily leak pools or destroy the stack order when you push and pop pools from multiple threads.
3) you could also leak pools in multithreaded contexts
Unfortunately, autoreleasepool crashes are some of the hardest to debug. Start with the static analyzer, which can find some things.
Then turn on NSZombies.
Your XmlWrapper object is a bit strange. Why do you immediately release it as soon as you create it? Is this a wrapper around NSURLConnection? You should still hold onto the object so that you can cancel it or clear its delegate when this object is released.
Make sure you're using accessors for all your ivars rather than accessing them directly. Direct access to ivars outside of init and dealloc is the #1 cause of these kinds of crashes in my experience.