is the console output in XCode the equivalent of the error message window in Visual Studio? - xcode

The only error I ever get is SIGABRT in main. This is getting incredibly frustrating as I have to guess what line caused the error and why.
This is a far cry from visual studio's informative error messages. It's basically like sending off an entire novel to an editor and the only notes you get back are: "There is a problem somewhere in your book. There may be many or just one and they are either gramatical or to do with spelling."
I just don't know how anyone can work like this. What am I doing wrong? Surely I'm missing something essential.

Write some NSLog() into your code and you'll see it in the console. It's a great help to narrow down a crash.

if you have encountered memory problems (aka – your app crashes for no apparent reason because you attempted to use an object that you deallocated to soon) setting NSZombieEnabled = YES can help you diagnose the problem.
Normally, when your app crashes in this way and you look at the log it tells you nothing (thanks Apple!). However, if you select your executable (under Executables in Xcode), hit the info button (round blue thing at the top), select arguments and put this in the bottom screen NSZombieEnabled = YES the log will give you more information.
Now, if your app crashes the log will have an indication of the object you attempted to access that has already been deallocated. Not forget to turn it off before you deploy it – you don’t want a bunch of nszombies running around your clients phones…
http://howtomakeiphoneapps.com/nszombie-and-xcode-oh-my/27/

Related

Xcode log "Writing analzed variants"

Running Xcode 13 I see the following log when launching my iOS app in the Simulator:
Writing analzed variants.
Note that this is, hopefully, a misspelling of the log:
Writing analyzed variants.
What is causing this log noise? Is something in my code triggering it?
How can I hide this "Writing analzed variants." Xcode log?
According to Quinn “The Eskimo!” at Apple Developer Technical Support, this message is Xcode log noise and can be ignored.
An Apple bug report should be filed to help flag and silence the log.
https://developers.apple.com/forums/thread/689066
https://developer.apple.com/forums/thread/115461
It’s important to keep an eye on log messages and fix any obvious problems they call out. However, if you see a log message that’s not obviously your fault, it could just be log noise.
There are two criteria you should apply here:
Is the log message associated with a specific failure? That is, when you see the log message, do you also see other problems?
Is the log message written in terms you understand? That is, does it reference APIs or data that you’re using?
If the answer to both of these questions is “No”, it’s reasonable to conclude that the log message is just noise and you can ignore it. If you find it to be particularly irksome, file a bug report requesting that it be silenced.
For me this issue warning coming because of keyboard was not working in my simulator, I have made some mistakes in my code in SceneDelegate for window initialisation, but once I have removed that line of code this message not showing in log/consol
these 2 lines I have removed from SceneDelegate, these two lines created this issue for me
let windowScene = UIWindowScene(session: session, connectionOptions: connectionOptions)
self.window = UIWindow(windowScene: windowScene)
So I have removed these from SceneDelegate
for SceneDelegate Code and the keybaord issue see this
This was annoying me because the log lines seemed to be causing a delay, which made my UI feel sluggish. I tried a number of ways to speed up my segue code before seeing the lines in the log and thinking they might be taking time.
I was using a custom keyboard which didn't have an equivalent in iOS, and I'd left "Use the Same Keyboard Language as macOS" selected in the Input > Keyboard menu. Turning that off got rid of the logging, and fixed the associated slowdown.

When only "All Exceptions" breakpoint is set, Xcode 7 always stop on app start

It's been bothering me since Xcode 6, that whenever I set 'All Exceptions' without any other breakpoints, Xcode would stop at start when I init a UILabel view wrapper in RootVC.
If I try to remove the causing line, another "random" line would trigger it again. Thoughts on what caused the exception?
This breakpoint comes from an exception that was thrown by TFileDescriptorContext. All Exceptions halts also on C++ exceptions.
It gives you a good indication where the problem comes from. Take a look if all fonts that are listed in Info.plist are part of your application bundle.
"Normally" you are not interested in C++ exceptions when you are in Objective-C, so feel free to ignore them.
Edit: This problem has been discussed several times here on SO. Updating when I can find the posts again which might give you even a deeper insight.

How to debug Dojo in browser?

I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.

How can I know because myapplication crash?

Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH

Error in BIO read. Program will now exit

A message box periodically pops up with the title "Event Notification Application" and the text "Error in BIO read. Program will now exit"
Can anyone tell me what this error message is about? It occurs in a production environment and I have no idea where it's comming from.
Any clues very much appreciated!
We had this error message on an IBM xSeries and it was caused by the LSI MegaRAID Storage software. Use Process Explorer and check the properties of the pop up.
If it's actually BIO_read (with underscore), then it would be related to OpenSSL. Of course, whoever put the message there might have dropped the underscore - so I'd look for applications using the OpenSSL DLLs (libeay32.dll, libssl32.dll).
I've used Process Explorer to diagnose these issues before: start it when the message is showing, click the bullseye icon on the toolbar and hold it down, then drag over and release when the bullseye is on the target window. The process will be highlighted in the main program area. Also, check your Application event log for errors, and see if you have any services that are set for automatic startup that are not running after you close the error dialog.
For what it's worth, I'd bet this issue is related to an auto-updater for some software installed on your machine. Try to identify those auto-update services (I bet McAfee has one) and disable them for a time (if that's safe.) Only disable one at a time so you can be reasonably sure which one the culprit is; be sure to enable it if it is ruled out.
Best of luck!
Do you have norton installed? It seems to be related to Norton 2000's live update.
Try disabling that and see if the error goes away.
The culprit was some raid software.

Resources