strange warning in my debug window - iphone

I'm updating my application to iOS 7 and I've run into some problems. I'm making a calculator and it isn't functioning the way I wanted it to be. I got it working in my iOS 6 version but not in 7. I'm wondering if it has something to do with the message below. There are multiple messages identical to this one for different classes.
Aug 12 22:22:29 My-Macbook.local myApp[3640] <Error>: CGContextSetStrokeColorWithColor<--**This class changes multiple times for a different message**: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

These messages were related to a bug in Xcode during the beta period. Please make sure you upgrade to the latest production version of Xocde (5.0.1). I do not believe this is linked to your development issues.

Related

Realm Swift: Handling/preventing sync error 108

I've been testing the new platform over the last couple weeks and have had trouble with syncing reliability, occasionally getting an error 108 inside the SyncManager.sharedManager error handler. I see from the documentation that error is described as:
“Client file bound in other session (IDENT)” Indicates that multiple sync sessions for the same client-side Realm file overlap in time.
However, I'm not really sure what this means or how to go about debugging it. Any advice?
solved... maybe?: I found there is a logOut() method in the RLMSyncUser class which seems to flush any open sync sessions. I've added this to my error handler which will hopefully reset sync states.
This was an issue with older Realm Object Server versions, but has been fixed since version 1.0.0-BETA-2.2. Please update to a newer version of the Realm Object Server. 1.0.0-BETA-4.2 currently.

CGContextAddPath StoryBoard issue

Firstly i have experienced AUTO LAYOUT issues in StoryBorad.When i have resolved these issues now two new errors are occurring. Please let me know if any one have any idea about these errors.
Errors are giving below:
: CGContextAddPath: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
: clip: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.

CGContextSaveGState error

i am working on iphone app, at once it started showing me error, with no exception, i am really afraid of this error, can any one tell me why this is happening?
<Error>: CGContextSaveGState: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
Issue exists in iOS 7. It´s a known issue on which Apple is working on. Should be fixed in the next beta release.

ReleaseHandleFail after upgrading to .net 4.0, possibly related to EntityFramework

I recently upgraded an application from .net 3.5 to 4.0. Since I did that, with debug settings to break on all exceptions enabled, I've been getting a few of these exceptions each time I start a section of the application that connects to a database using the EF. The exact number is variable; sometimes I only get one, others several in rapid succession.
ReleaseHandleFailed was detected Message: A SafeHandle or
CriticalHandle of type
'Microsoft.Win32.SafeHandles.SafeCapiHashHandle' failed to properly
release the handle with value 0x06AD3D08. This usually indicates that
the handle was released incorrectly via another means (such as
extracting the handle using DangerousGetHandle and closing it directly
or building another SafeHandle around it.)
I never got exceptions like this when targeting 3.5. These exceptions don't have any meaningful call stack attached, all I get is [External Code], denying any easy way to localize where they're coming from. The reason I suspect EntityFramework is somehow involved is that one section of the app uses nHiberate instead doesn't generate any of these messages.
To run down other dependencies that might be involved: In all cases, the ORM is talking to an Sql Compact database MS Sync Framework 2.1 is being used to update the local DB from SqlServer. The Entity framework models have been regenerated with the 4.0 framework, and I upgraded the cache DB to v4.0 as well.
Since there's no call stack I'm not sure if these messages fall into the category of "harmless" errors automatically cleaned up internal to the framework; or if there's an exception eater catching them elsewhere in the application.
This is not an exception, it is a Managed Debugging Assistant warning. You might have gone over-board a bit when you changed the settings to "break on all exceptions enabled". Debug + Exceptions, Managed Debugging Assistants node, untick the "ReleaseHandleFailed" warning. It is off by default.
The MDA catches an old bug that's gone undetected for a while in the AesCryptoServiceProvider class. Backgrounder is here.
Judging from your comment, you are about to make a drastic mistake. You do not solve this by avoiding encryption or compromising your dbase connection security. You accidentally turned on an MDA that's normally off. MDAs in general tend to produce false warnings and many of them are turned off by default. The warning is in fact bogus, releasing the handle failed because it was already released. This happens in the finalizer thread, that's why you don't get a stack trace. And thus can't easily find out what code uses the class in the first place.
The proper way to fix it is to use the Debug + Exceptions dialog properly. Fix the problem you created by clicking the Reset All button. Then click only the Thrown checkbox for Common Language Runtime exceptions. That's what you are trying to debug.

Track down out-of-bounds access on iPhone

I work on an average (~ 20k lines of code, Objective-C mixed with C++), and I am figthing to hunt down an EXC_BAD_ACCESS error.
I have tried all the common techniques (like enabling NSZombie, guard edges,etc.) So far, I have ruled out the possibility to access a released object, and the double-free error.
It seems that something writes on a memory space where it shouldn't. But, as many memory errors, it's not happening all the time, and it's not crashing always in the same place.
(Sometimes I receive the "object was modified after being freed" message).
Sometimes, the overwritten memory belongs to the allocator, and it crashes on malloc, or on free().
And, of course, some changes in the app may influence the bug's behaviour - if I try to comment out parts of the code, the error appears less often, so it's more difficult to find it.
Finally, I have been looking into using valgrind, but it seems that all those who used it worked on the simulator. but my code must run on the actual device (some code is ARM-specific)
Are there any general tips on how to debug such errors?
Note: The app involves video processing, so the amount of memory used is fairly large.
There are some special tools available on the XCode. You could try to use them in order to analyse your code.
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/index.html
It will produce some warning in case of invalid objects usage so it could help you to find a problem.
If you feel that the C++ code is causing the issue you could copy the C++ out of your iPhone project and create a Mac project. With this you could set up various stress tests. And, you should be able to use valgrind as well.