Im trying to use Date Formatters (NSDateFormatter), but I keep getting this error:
Program received signal: “EXC_BAD_ACCESS”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
This is nothing to do with NSDateFormatter - the message pasted in saying "Data Formatters" is correct. You will get this message in several situations, possibly most commonly when unable to find a linked in shared library at launch time. You may also get it when short of memory while running, in which case start looking for leaks.
(not enough rep to comment).
I've had the "Data Formatters temporarily unavailable..." problem when I put a breakpoint in an unusual position (such as on the exception handler). In the Debugger window, click on "Show Breakpoints" and see if you have something you forgot about -- I did.
I had the same issue, building the code on 3.2 as target solved the problem. Maybe this can give a hint, as i am not happy with this solution.
I just solved the same problem. Mine had to do with stack overflow (no pun intended ;-) since I was overriding a setter and calling the same setter from within, forming an endless recursion. Hope that helps.
In my case, this was the cause:
NSLog(#"%#", url);
where url is a NSURL, not NSString.
This wasn't a problem in the simulator, but it generated the "Data Formatters temporarily unavailable" on the device.
Related
The following message keeps getting logged to the console:
-[__NSCFSet minusSet:]: This app appears to be calling this method with
a non-set parameter. Please wait while the system corrects this...
I don't know what I did to this appear. I never call this function and don't know what things call this.
For me, this appear when a touch anything in my UIWebView. This can be a touch in text box, or just a simple touch in any area of the page. Any new touch will produce it.
Anyone have an idea how to solve it?
You should be able to find out whether your code is causing the log message or not. You can do this by interrupting the app when the message is logged and looking at the stack backtrace of the logging thread. Then, investigate what code created the object that is prompting the log message using malloc history or Instruments.
To start with, you can try adding a symbolic breakpoint on -[__NSCFSet minusSet:]. You could narrow it down to the actual code doing the logging if you looked at the disassembly for a call to NSLog and placed the breakpoint there.
Once you've ruled out your code, it's not your fault: it's time to file a bug report and move on. If the log messages are swamping more interesting log messages, you might try patching the binary so it doesn't log, but just living with it is likely to be easier (though much less fun).
ERROR,Generic,Time,320195751.128,Function,"void
CLClientHandleRegistrationTimerExpiry(__CFRunLoopTimer*,
void*)",Registration timer expired,
but client is still registering!
There are only a few mentions of this problem that I was able to dig up in the wider Internet, and nobody has useful info. Here's the context:
I have an app that monitors the device's location via CLLocationManager's startUpdatingLocation method. It starts monitoring, runs for a little while, then this message pops up in the debug output. From that point forward, no more location updates are delivered.
This error is killing the location functionality of the app, and I'm at a loss as to what may be causing it. It even has an exclamation point at the end, which means it's clearly an exciting error.
Update:
Though I never found a solution to the problem, or figured out why it happens in the first place, I've also lost the ability to reproduce it. This seems to have happened during some period of time in which I did many things, including a general change in code structure followed by update to the iOS 5 beta. Something there seems to have silenced the issue for me.
Have you implemented
- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error
and does this catch it?
You need to check for kCLErrorNetwork, kCLErrorDenied, kCLErrorHeadingFailure and kCLErrorLocationUnknown in the normal run of things but I'm wondering if there are other errors that the delegate can still catch?
This could give you the opportunity to stop and then restart location services.
Going off of what #schillace had to share, is it possible that you're attempting to force location updates without heeding the user's authorization status?
Try to hold off on calling -startUpdatingLocation until you know that [CLLocationManager authorizationStatus] == kCLAuthorizationStatusAuthorized.
I don't know if this is the answer or not, but here's a hint...I'm working with assetFromURL and I'm getting intermittent failures to load images from the asset library. So I wrote a bit of code to test a theory, that loads every url in the library very quickly. I started seeing this error with this bit of code.
So...my theory is that if you make a call that causes the location manager to show the "app wants your location" dialog, and then you continue to make calls while that dialog is up, you'll get this error. Once I acknowledged the dialog and re-ran the program, I didn't see this error any more.
Hope that helps, it's just a guess.
Are you sure this is a problem? It looks to me like you are debugging to a breakpoint (effectively suspending the application) before the registration to the location manager is completed. Meanwhile, the timer expires and you haven't finished your registration. If you take out the breakpoints, does the message ever appear?
Are you doing location stuff on the main thread? I had all sorts of bizarro issues with CLLocation API calls from a background thread. I moved a couple of key setup calls into the main thread, then everything worked fine.
I got the same error and figured out that it was because I had forgotten to mention that the class implements the CLLocationManagerDelegate in the .h file.
Adding the CLLocationManagerDelegate to the header file, and the following line to point to the delegate solved the error for me.
locationManager.delegate = self;
[locationManager startUpdatingHeading];
I got this when implementing the timeout (perform selector after delay) in LocateMe, my previous code used another method. I don't know if this is a clue.
I had forgotten to add
Privacy - Location When In Use Usage Description
I did that and the error went away for me.
in my application bus error is showing and application crash ..i want to know when this error comes . what mean by bus error ?
in my application page on diffrent id i have to calling libxml parsing . in many times calling, ones it crash .
Usually bus error occurs when you are trying to access a deallocated object. Set NSZombieEnabled to check which object get released.
As getluky states in his answer on Unity Answers:
I've seen SIGBUS often occur on NULL reference exceptions that occur
at runtime. They are usually fairly straightforward to track down via
the XCode debugger - hit the Continue button a couple times while
monitoring the XCode debug console output. It usually will give a hint
as to what file and line number the null reference was in.
Not sure why recreating the XCode project would fix it - it's usually
an issue that recurs unless I can fix the underlying problem
I'm able to complete my iphone app using core data internally.
But for the first time when I'm running in simulator or on device its crashing with following error:
2010-03-18 10:55:41.785 CrData[1605:4603] Unresolved error Error Domain=NSCocoaErrorDomain Code=513 UserInfo=0x50448d0 "Operation could not be completed. (Cocoa error 513.)", {
NSUnderlyingException = Error validating url for store;
}
When I run the app again in simulator or on device, its running perfectly. I'm not able to identify the exact problem. Can some one guide me on how to proceed further???
You need to unroll the errors and see what is going on. Inside of that error (which you can set a break point on objc_exception_thrown to catch it) is the userInfo dictionary which you can interrogate to see what the underlying errors are.
update
What does your NSPersistentStoreCoordinator creation code look like?
Did you add a break point and do a po [error userInfo] so see if there were any additional errors in the userInfo?
Core Data can and does send you a hierarchy of errors and frequently on a small amount of information is exposed at the top error. Unrolling the errors via the debugger is best to determine the underlying causes.
update
Code error 513 means, write permissions for creating store in core data app failed. But the same piece of code is running well from next time. So, what might be the actual problem is not known to me..... how to proceed here.
Again, what does your persistent store creation code look like? You need to post some code so that I can take a look at it. Otherwise I am just guessing which is no fun.
8.2 has become more strict on the location (and permissions) of your persistent store. I've just seen the "513" error appear when the database was stored in the bundle and used with a read only option. Using a device with 8.1 it worked without failing, but on 8.2 the error and exception appeared causing a crash. On the simulator the exception did not occur and happily continued to work.
The solution that worked to copy the database into the application documents directory at start up.
NSFileManager copyItemAtURL:toURL:error will come in useful.
I'm getting the following error
Program received signal: “EXC_BAD_ACCESS”.
warning: check_safe_call: could not restore current frame
warning: Unable to restore previously selected frame.
warning: Unable to restore previously selected frame.
My app is to get wifi information
libHandle = dlopen("/System/Library/PrivateFrameworks/ MobileWiFi.framework/MobileWiFi",RTLD_LAZY);
open = dlsym(libHandle, "Apple80211Open");
bind = dlsym(libHandle, "Apple80211BindToInterface");
close = dlsym(libHandle, "Apple80211Close");
scan = dlsym(libHandle, "Apple80211Scan");
open(&airportHandle);
bind(airportHandle, #"en0");
When the code reaches open(&airportHandle), I receive the error but I'm not sure because at this line it stops.
How can I resolve this?
For any EXC_BAD_ACCESS errors, you are usually trying to send a message to a released object. The BEST way to track these down is use NSZombieEnabled.
This works by never actually releasing an object, but by wrapping it up as a "zombie" and setting a flag inside it that says it normally would have been released. This way, if you try to access it again, it still know what it was before you made the error, and with this little bit of information, you can usually backtrack to see what the issue was.
It especially helps in background threads when the Debugger sometimes craps out on any useful information.
VERY IMPORTANT TO NOTE however, is that you need to 100% make sure this is only in your debug code and not your distribution code. Because nothing is ever released, your app will leak and leak and leak. To remind me to do this, I put this log in my appdelegate:
if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled"))
NSLog(#"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");
If you need help finding the exact line, Do a Build-and-Debug (CMD-Y) instead of a Build-and-Run (CMD-R). When the app crashes, the debugger will show you exactly which line and in combination with NSZombieEnabled, you should be able to find out exactly why.
EXC_BAD_ACCESS always occurs when accessing memory you already have released. In your sample code, I can't see where airportHandle is initialized, or wheter it is initialized at all for that matter.
If it has been initialized but you just forgot to post that code, you should try checking if you released the handle somewhere.
To debug such an access violation, it is often useful to set the NSZombieEnabled Environment flag to YES. This will cause the Obj-C runtime to log access to released memory to the console. You can find a full tutorial on how to use that information together with Instruments to find your problem.
You can do it EASILY with Instruments: See this really great post:
http://www.corbinstreehouse.com/blog/2007/10/instruments-on-leopard-how-to-debug-those-random-crashes-in-your-cocoa-app/comment-page-1/#comment-43762
EXC_BAD_ACCESS. is mainly found when u released any object which you have further needed in future.it is unable to find but there is solution to find out u must have to be in a DEBUG mode . then follow these links
http://www.codza.com/how-to-debug-exc_bad_access-on-iphone
it really works
I'm working on the same thing, and I get the same issue. If you enter in debug mode, you can see that when we use open = dlsym(libHandle, "Apple80211Open"); the function still equals to 0.
So in my opinion you are looking for the Apple80211Open in a framework which did not contain this function.
Apple80211Open is in the Apple80211 private framework which is outdated in >iOS 2.x SDK. The equivalent in the MobileWifi framework, which is for the 3.x and 4.x SDK, is /System/Library/SystemConfiguration/WiFiManager.bundle/WiFiManager instead of /System/Library/PrivateFrameworks/MobileWiFi.framework/MobileWiFi