When I run my application it works well, but during transitions between its views I have a lot of CGContext errors in the console output, but the app still works well, no crashes or bugs I didn't see. Description: so I only run my app - all work well - but there appears error messages in the console:
And after any other view transition they appear again and again. So the question - how to fix this? And what may be the reason of this error messages? There a lot of views and code in my application so I don't even know what part is error-prone.But these messages appear after transitions between all views in my app. Thanks in advance.
Look for some method in your code where you call CGContextSaveGState, CGContextSetBlendMode, CGContextSetApha, etc. Chances are that you won´t find many places where you do that.
Well, if you find it, look for some statement (just before those listed in your console log) where a context is created, and try to understand why it fails. You may set a breakpoint on that line and inspect the parameters to the CGContextCreate call.
If you need more help, paste the code you have (hopefully) found.
Related
My app has crashed telling that he index is out range when I use this team[1] which is surprising because it should have 2 strings in it. I have looked everywhere, in XCODE and the internet, but cannot find a way to see what the team array looks like. Is there anyway to see this? Thanks so much!
click on the left side of your line of code which contains (team[1]) to create a breakpoint.
Then run your app. When it reaches that point it will stop executing so you can check what is going on.
Here is an screenshot on how debugging looks like
You can see your array content in the "variables view"
There is also an example of "po" command on the "console" section
If you just want to use a breakpoint everytime your app crashes just add an exception breakpoint. This should show you where your code crashes and stop just before so you can find out what happened
I like to use these to debug (can you tell I'm a noob?) and have left them in my code as is when deploying to the app store. Are there any negative implications for this you can personally think of?
I have looked at these resources and I am getting the feeling it's not a good idea:
http://doing-it-wrong.mikeweller.com/2012/07/youre-doing-it-wrong-1-nslogdebug-ios.html
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/LoggingErrorsAndWarnings.html#//apple_ref/doc/uid/10000172i-SW8-SW7
This was also a good resource:
http://www.theonlylars.com/blog/2012/07/03/ditching-nslog-advanced-ios-logging-part-1/
That said, when you ship to the store and DO keep NSLogs in there, what have you logged?
Create a snippet with the above settings. Where it says "debug statement", replace that with:
<#debug statement#>
Now, since the completion shortcut is set to "NSLog", every time you start typing NSLog, it will autocomplete to this snippet and you will have the "debug statement" part selected and ready to type over.
You'll never have to worry about commenting out your NSLog statements again, and you'll never have to forget about using #if DEBUG since the completion shortcut is what you would type anyway.
Apple's Official Documentation for creating a Snippet (I've included this link because I think it's really kind of sad that this is apparently the only way to do it?)...
And my explanation...
Copy and paste the following code into Xcode:
#if DEBUG
NSLog(<#debug statement#>);
#endif
Select the entire code block you just copy-pasted. Click, hold, and drag this code block down to the snippets section (usually in the bottom right corner).
Select this snippet to get a screen like this:
Click "Edit" and fill out the details. Give it a title and description. Leave platform on "All", and language on "Objective-C". Set the completion shortcut to "NSLog", and leave the completion scope on "Function or Method" (what this option defauts to may depend on where you pasted the code to originally and where you dragged it from).
As Aaron Brager's answer points out, NSLog could be a performance concern, particularly in loops (also in places that don't seem very much like loops but actually are, like cellForRowAtIndexPath...).
But more importantly, you may be exposing information you don't necessarily want to be made publicly available.
I'm not saying there doesn't exist something that might be useful to include to present to the end user in the log statements, but personally, I've yet to find it. How many times have you ever investigated the output of an app's log statements to diagnose an issue you were having with it? How many times have you contacted an app developer and they asked you to check these statements to help diagnose a technical issue you were having?
The Mike Weller post you linked makes the right call. NSLog is for user-facing warnings.
There also might be performance issues, especially within loops, since it uses a string formatter.
You can and should use DDLog or other tools to ignore the debug messages when you make your release build.
I am getting an EXC_BAD_ACCESS. I know what this usually means: Trying to access an object that doesn't exist (anymore) is the most likely cause.
So, where do I find that?
I have read numerous posts on the internet, and they all say:
"Enable NSZombie" in the scheme.
Now when I run the debugger, for what should I look? I can not see any difference...
Note: This is not about a perticular error in my code, but generally how to use the debugger with NSZombie enabled
What I would do it will be to locate a breakpoint just one line above the green arrow showing the EXC_BAD_ACCESS error. Then run again your code and reproduce the steps to generate the crash.
When you get to your breakpoint you can check that your objects are valid objects using right click and print description in the left side of your console within Xcode or typing the command 'po' within the console section in XCode. That's how I usually detect the errors.
Something useful is to trace the stack once the debugger stopped. It show in the left panel the threads and chain of invocations of the methods before the break point.
Hope this helps and hope my description of the alternative in how to track the error helps.
Write code in #synchronized(){} block.
Try this:
#synchronized (self){ //Your Code }
I'm getting a weird error while trying to click on a Capybara Element
I'm using find(:xpath,"//a[contains(text(),'Connect')]").click
(find(:xpath,"//a[contains(text(),'Connect')]").present? return true)
the error I get is:
Selenium::WebDriver::Error::MoveTargetOutOfBoundsError Exception: Element cannot be scrolled into view:javascript:void(0);
i did some research and the only solution i found is that setting the selenium version to 2.16 may fix this issue (i'm using 2.25).
anybody got an idea?
It may happen when the page being tested is not fit into the current window size. If you know such pages where usually these error happening, you may explicitly scroll down before doing the operation on such hidden elements(like click, clear etc). Here the code to explicitly scroll down the page.
In java,
JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("javascript:window.scrollBy(250,350)");
From the times I used selenium webdriver to test .NET apps, I would get that error when the issue was exactly what it sounds like: It's looking for an object on the page that it cant scroll to for some reason. In my case it was because some dialogue boxes would appear without scrollbars and the driver had no way to "scroll the object into view"
Can you watch the execution of your test and see if that's the case? I had some luck rolling back to a previous version of firefox because 15+ was (as of about 2 months ago when I had the issue) unsupported by web driver and had this problem periodically. Rolling back selenium versions may help too.
First step though is definitely to watch the execution of the test and see whats happening though. And a good debugging idea may be to try to work through your steps manually yourself to make sure the test works by hand.
Its also worth noting that for the webdriver to be able to execute click the object actually has to be visible. IsPresent doesnt require that, it just searches the page files. Also an issue I ran into. IsPresent will still return true for objects that are not and cannot be made visible on the page (i.e. something at the bottom of the page that you cant see at the time)
Couple of tips here:
Webdriver should ideally be on the most recent update, it's what most use (Unless you're doing Ruby Automation)
Use css selectors, xpath (Whilst rendered), is almost always heavier on both resources and code.
Try defensive coding, first of all ascertain it exists. There are many ways to do that dependent on what package you are using. In ruby you would do page.has_css?('css_string')
What does the following error indicates
5/19/11 8:06:45 PM SpringBoard[9712] Error deserializing
wallpaper image: Error
Domain=CPBitmapErrorDomain Code=0 "The
operation couldn’t be completed.
(CPBitmapErrorDomain error 0 - No data
provided to
CPBitmapCreateImagesFromData)"
UserInfo=0x70b9c80 {NSDescription=No
data provided to
CPBitmapCreateImagesFromData}
Well, if you read the error message, it is telling you that a wallpaper was unable to be deserialised because no data was provided to the function named CPBitMapCreateImagesFromData. Pretty self explanitory.
Other than that, it sounds like you're either working on a jailbroken phone or trying to do things that aren't supported by the official iOS SDK - in which case my help ends here.
Or you're a user who is trying to understand why an image they set as a wallpaper isn't displaying and found their way to the iPad's console - in which case, this isn't the place to be asking.
This happened to me also, I think it's because most of the tutorials are written with an iphone in mind and I was using an iPad. I was working with an ipad and when following these tutorials i was getting this problem.
When you are creating the project I choose View based application. In the same wizard there's a combo box for 'iPhone' and 'iPad'.. If I leave that as iPhone then my application doesnt start in the simulator and I see the error you mention. If I set that to iPad then everything works fine.
I dont understand why that should make a difference tbh..
This happened to me, but only when I was not debugging, what happened was that in the dealloc function [super dealloc] was called at the top of the function rather than at the end. The "deserializing wallpaper" message is probably due to some sort of memory corruption that occurred since I had code after [super dealloc] trying to use pointers that were now garbage. I had NSZombie activated but it had no effect. Why this only crashed when I was not hooked up to the debugger is beyond me at the moment.
Thankfully this bug was fixed after a few diffs in source control, but initially I was pretty perplexed at the message and the fact that it was a bug where the debugger couldn't be used only induced more panic.
I'm sure you've long fixed your problem but I thought it'd be helpful to put this out there for others.