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.
Related
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.
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.
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.
i used Bugsense framework in iPhone application to get the crashe logs, and it works fine.
but when i get the crash report from iTunes account, the crash report indicate that there is a crash in bugSense framework.
What this is mean? is it indicate that crashes in applications reported by bugSense ? or it is actual crash in the framework itself?
Please Help.
Thx
It could be, that this is a crash in their SDK. Sadly they perform non-async safe functions in their framework once the crash happened. See http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html for more details on what that means (in this case calling Objective-C code once a crash occurred is unsafe). You might want to contact them to make the fix this possible problem.
But the messages lower in the stack trace also indicate, that this is a crash that happened because of an uncaught exception occurred, which would normally cause another Last Exception Backtrace to appear on top of Thread 0. I am not sure if they have that functionality included. If they do, this causes that block only appear in their own crash report but not in the crash reports iOS creates. Then this is nothing to worry about, except that code above being bad as already mentioned.
If you have enabled immediate dispatch in BugSense, this is probably the reason of this crash, as it isn't guaranteed to be safe.
For more info you can check this: https://github.com/bugsense/plcrashreporter-bugsense/wiki/Using-the-BugSense-2.x-iOS-library , section Enabling immediate dispatch
this may happen when there is no internet connection, try enable immediate dispatch in bug sense
Program received signal: “EXC_BAD_ACCESS”.
[Switching to process 388]
kill
error while killing target (killing anyway): warning: error on line 2179 of "/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
quit
The Debugger has exited with status 0.(gdb)
Program received signal:
“EXC_BAD_ACCESS”. [Switching to
process 388] kill error while killing
target (killing anyway): warning:
error on line 2179 of
"/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c"
in function
"macosx_kill_inferior_safe": (os/kern)
failure (0x5x) quit
Note where the error is; gdb has crashed. This is potentially due to a crash in your application, but that particular messages is certainly not useful to debugging the real problem.
And, more likely than not, the actual crash has nothing to do with an over-release of an object. Maybe so, but likely not.
Typically, when GDB crashes in this fashion, it is because you trashed the heap or stack in a fashion that gdb trips over the corruption trying to figure out what is going on. Or your app has entered a state that gdb can no longer communicate with it (which might be the case here given the crash location).
In this case, some things to try:
using latest dev tools? If not, do so and rebuild your app from clean, too.
can the crash be reproduced on the simulator and the device? If so, can it be debugged properly on one but not the other?
if you run the app without the debugger, can you get it to crash and then extract the crash log from the device?
does the behavior change between debug and non-debug builds? That can greatly impact memory corruption.
did this just start happening? If so, what did you change most recently?
Thought of another trick;
try setting the MallocScribble environment variable. This will scribble values into memory upon allocation/deallocation and can often, at the least, cause a memory corruption related crasher to crash earlier or different enough to catch it.
EXC_BAD_ACCESS usually means you are trying to access something that doesn't exist anymore. We'd need your stack dump and probably some code to help you figure it out.
To quote a co-worker, "Something went wrong somewhere".
This means that you have attempted to access a pointer that is no longer valid. Perhaps you forgot to retain an object, or released it one too many times?