Shouldn't Xcode/gdb load the ~/.gdbinit file on launch? - objective-c

I have a ~/.gdbinit file which is loosely based on How do I set these break points in ~/.gdbinit?. Allegedly, gdb is supposed to source ~/.gdbinit when it launches. However, it's not loading mine - I have to stop at an existing breakpoint and type in 'source ~/.gdbinit', and then it loads it. Is there a way to have gdb or Xcode do this automatically?

Xcode possibly invokes gdb as gdb -nx ....
There probably is some setting somewhere in Xcode to change that.

Related

Xcode throws an exception in Main() in iOS 8 with 'all exceptions' breakpoint

I am using Xcode 6 (GM, I didn't download betas), and I am developing apps for iOS 7+. For all my projects, I just opened the same projects I used to work on in Xcode 5.
In the Breakpoint navigator, I have the All Exceptions breakpoint on. It is set to Break: On Throw. Now, each time I run my app (whether on a device or in simulator), it stops execution on the line return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); in the main() function.
If I press Play to continue program execution twice, the program runs fine. So this doesn't prevent me from working, but it is annoying to have to manually play the execution each time and reset my editors.
I like the behaviors I have set up in Xcode (taking the current editor to where the execution has paused), and having that All Exceptions breakpoint is important IMO. (So I don't want to change those)
By running the same code, with the same environnements, for an iOS 7 target (again, device or simulator), the exception is not thrown.
Any clue what could cause this strange behavior?
As stated in the comments, you should turn off catching the C++ exceptions by editing your All Exceptions breakpoint.
In order to do that, right click on your breakpoint and change Exception from All to Objective-C:
Exceptions in C++ code are part of normal app functionality. However, exception breakpoint is not catching unhandled but every raised exceptions, even when they're handled correctly later on, hence the stop in execution.
TLDR; In my case the cause of problem was missing fonts.
I also had this problem. While #Johnnywho is correct that leaving Exception Breakpoint for Objective-C only, stops the unwanted behaviour, it still does not explain what is the real cause, why does it run without exception on iOS7 and why does this happen only on some projects.
That's why I went on and dissected one of my projects in which I had this problem, until the point where I was able I found the cause. I suppose that there could be more than one cause for this behaviour, but in my case that was missing custom fonts.
Quick way to test it:
Start a new single view project
Enable breakpoint on all exceptions, including C++ (Breakpoints / + / Add Exception Breakpoint)
Drag into the project some custom font (allow copying and check the target to add it to)
Add a label to the view in the main view controller
Choose the custom font for your label (on Xcode 6+ it should show in the font picker as soon as you drag it into the project).
Run the app and confirm that you see the label in your custom font (it seems that we don't need to add the font file name in Info.plist for the key "Fonts provided by application" anymore, if the custom font has been used in a storyboard of xib of the app).
Now remove the custom font from your project (either by unticking target relationship or by removing it in target settings / Build Phases / Copy Bundle Resources)
Delete the app from your device or sim (to delete the font file from the app bundle)
Product / Clean
Run the app again (now the label still has the reference to the custom font but the app does not have the file for it). You should notice the mysterious exception if you run on iOS8.
Run the app on device with iOS7 or sim with iOS7 (you'll need to change the iOS Deployment Target to iOS7 for that). Although the label won't show the custom font, there won't be an exception.
Add the font file back to the target and the breakpoint does not stop on run anymore.
So my conclusion is that on iOS8 the missing fonts cause C++ exception while on iOS7 they don't, hence the breakpoint trigger.
Similar exception (and breakpoint trigger) can also be caused by incorrectly written font file name in Info.plist file under the key "Fonts provided by application".
Just summarized previous answers which helped me to fix it.
Problem: When you add custom font and then apparently delete (replace) it, somewhere in project is still his reference and the breakpoint stops several times at main C++ lib breakpoint stops in iOS 8.
Solutions
1) Find in project and delete (replace) all references to those fonts. Might in some nibs, submodules, etc…
2) If you can’t fix everywhere (e. x. read-only libs use them) or problem still exists after solution 1 , add those old fonts back to project
3) Ignore it - It is C++ lib so change breakpoint exception from “All" to "Objective-C" only
Xcode 9, sometimes there are exceptions that are thrown but iOS is catching it gracefully. This will help
source
for my case, it was a user-defined attribute in nib
I had a same issue, the issue was i have added some interface files from other project which has different font in it. Just find them and remove.

Cocoa failed to load window nib file when nib is localized

I'm trying to create and show new window in my simple Cocoa application:
myWindow = [[MyWindowController alloc] initWithWindowNibName:#"MyWindow" owner:self];
[myWindow showWindow:self];
It's working well with basic nib file without localization, but as soon as I turn on localization for this specific nib file (using Xcode "localize" option available form file inspector), the application gives me this error when executing the code above:
-[MyWindowController loadWindow]: failed to load window nib file 'AuthWindow'.
Should I change the way I'm initializing my window controller when using localized nibs? It fails only when nib containing a window is localized (with just one language - English), when there is no localization configured - the window is loaded and appears on the screen as it should. I can't find the right answer, I'm new to Cocoa on OSX, but have some experience with CocoaTouch and developing for iOS.
I restarted Xcode and the error went away...
I don't know... but whatever...
initWithWindowNibName: can locate a .nib file in a localization directory such as en.lproj/. The problem is, sometimes Xcode forgets to compile a .xib file (an Interface Builder file in XML format, which you usually play with) into a .nib file, or a binary format - especially when the .xib file is just localized by clicking "Localized..." button.
If you open $build_dir/Your.app/Contents/Resources/$locale.lproj you will find some xibs only copied from the source directory.
Relaunching Xcode will resolve the situation, while I'm not sure what the cause is and why relaunching does the trick.
It's an old question, but I found a different solution than those above. In the nib in question, go to the identity panel and make sure the nib's target membership is checked.
I had an error like this. What solved it for me was to make a backup copy of the xib file, delete it from xcode, restart xcode, then add it back. Go figure...

"Show Obj-c Only" flag hides all the content of call tree on xCode Instruments

I'm following this tutorial about Instruments. The tutorial provides a sample project to test the steps described on it.
The problem is that, when I check "Show Obj-c Only" and "Hide System Libraries" flags, all the lines in call tree list is hidden, but the code in the project is written in Obj-C. Is there something I have to change in the configuration to see the project lines as in the tutorial?
Call tree list image taken from the tutorial showing how it must to be:
Screenshot of my instruments execution:
Ok, I don`t really know what happens here, but now it works. How?
What I did:
Erase the app in the device
Kill xCode ( using activity monitor )
Restart the computer ( Only restarting xcode didn't work )
Restart the device.
Clean the project
Try again.
May be is not the best answer, but it worked for me.
[UPDATE] The issue is there again, so I try this: Xcode 4 Instruments doesn't show source lines
And it works!

View variable data while debugging in Objective-C

I come from a .Net world so I'm used to just hovering over a variable while debugging and seeing what its value is.
In Objective-C I am incredibly confused on how to do that.
If I hover over it, I get a small popup with lots of information...that doesn't help me at all.
For example, I have an object called "myServer" and it is an instance of a "Server" that I have created through CoreData. One of its properties is "root" which is a simple NSString.
I cannot for the LIFE of me figure out how to view what the value of [myServer root] is.
Can some please give me some advice on this?
In the gdb console, type
po [myServer root]
I like to use GDB from the command line. Open a terminal and type
gdb
attach <your process name>
(be sure your program was built with debugging symbols). Then, when your variable name is in scope (e.g. when you break somewhere relevant) type
po variableName
to view its contents.
Another nice way to deal with this is to log directly from a breakpoint.
To do this, create a breakpoint after the value you want to see has been set, then edit it. Add a breakpoint action of 'log', and put the expression you want logged within a pair of # symbols. Check the box to the right, ensuring that the breakpoint doesn't actually cause a stop. The value will be output to the debugger console on doing a run & debug.
Doing it this way you (a) don't clutter your source, (b) can dis/enable the breakpoint at will according to your immediate needs, and (c) don't need to stop execution.
This and other very handy xcode tips can be culled from Joar Wingfors' 'Debugging with Xcode' talk.

Xcode: I lost file type on one of my Objective-C .m files-- no more formatting, breakpoints, etc

Having taken no explicit steps that I'm aware of, Xcode has decided that one of my class implementation (.m) files is of unknown file type. So I've suddenly lost all colors/highlighting/autocomplete and (more problematically) the ability for the debugger to recognize breakpoints in that file only.
Right-click on the file and doing Get Info let me forcibly re-select sourcecode.c.objc as type, which temporarily restores the syntax highlighting, but it will eventually spontaneously revert to black on white text only. Breakpoints still won't work. Restarting Xcode doesn't clear this state. I cracked open my project.pbxproj file, and made sure that the attributes on that file are the same as all the other .m files. Restarted Xcode again. No dice.
Anyone seen this before and/or can tell me how to forcibly flush this state out?
Thanks!
What happens if you save it under another name?