I just started doing iPhone dev. At the moment I'm trying to fix a bug which exists in an already built app. The main function looks as follows:
#import <UIKit/UIKit.h>
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
This seems pretty typical from what I understand; I'm guessing UIApplicationMain is the main loop, which the source files that have been created for the app specifically connects to via the use of delegates/function pointers in Objective-C (note, while I'm quite proficient in C++, I hardly know much about iOS or Objective-C).
So, what I'd like to know is how I can step through my source files and track down the calculation bug I'm experiencing for this app. Unfortunately, all I receive is disassembly when stepping into the UIApplicationMain, and while I know the very basics of asm and can interpret it (for the most part), I'd rather not unless I absolutely have to - especially considering the fact that the debugger appears to be outputting AT&T syntax (NOTE: if it's possible to change the asm syntax to Intel, I'd appreciate it if someone could state how to do that).
Thanks.
You can put breakpoints on every line by clicking on the gray space between the code and the project explorer on the left. When running, upon encountering a breakpoint the simulator or device will stop running and the code will show up. Then hit either the down arrow button that will show up on the upper left of the debugging window at the bottom to go line by line, which will show asm when appropriate, or hit the right-pointing arrow which will run until the next breakpoint is hit. You can disable breakpoints by deleting them individually or by toggling the breakpoints button at the top.
The main function in iOS is almost identical in all projects. It just serves to get the ball rolling. Here is a good tutorial for debugging especially crashes in Xcode. debugging tutorial
(Answer to NOTE not the actual question)
xcode can be set to use gdb (in scheme settings):
simply add to your .gdbinit
(which is located in your home dir ) :
"set disassembly-flavor intel"
for lldb there might be something similar
Related
I am trying to migrate to using Xcode 10 on Mojave, coming from using Xcode 8.3.3 on High Sierra. I have a sizeable app containing a fair bit of legacy (non-ARC) code. The app is currently live in the Mac App Store, built with 8.3.3 on High Sierra.
I encountered problems with Xcode 10 and Mojave which took me down a rabbit hole, so I decided to back up and limit the migration to one step at a time. I'm currently attempting (unsuccessfully) to build and run using Xcode 9.4.1 on High Sierra.
Using exactly the same code base (new repo checkout) my app builds and runs fine using Xcode 8.3.3. It builds fine using 9.4.1, but crashes on running.
The problem appears to be memory/reference-counting related. I always get a crash when the app tries to show a window, and the trace is not very helpful. Runtime debug output consistently indicates that I'm sending a message to a deallocated object. Here's a typical stack trace:
stack trace
Whenever the app tries to show a window, I get messages such as (the old favourite) "message sent to deallocated instance". I don't always recognise the receiver as being one of my properties, so it looks like this is just a symptom, not a cause. Here's a typical message:
*** -[NSCalibratedRGBColor release]: message sent to deallocated instance 0x60000605ce60
I've tried in vain to get anything back from Xcode's diagnostics, such as zombies and malloc scribble. Radio silence. Also the static analyser reports no problems.
All I can think is that manual reference counting is somehow being treated differently by Xcode 9. I've checked through all the build flags to see if Xcode 9 changed anything. No changes. I've checked the release notes and can find no mention of changes to reference counting.
I can push the problem around by commenting out the display of various panels and windows, but the crash always takes the same form.
Has anyone else come across similar issues and found a solution? Am I missing something with Xcode 9? Any help greatly appreciated.
Thanks #sdarlington and Willeke for very helpful answers. I finally found and fixed the problem. I did have to use the caveman approach and gradually remove stuff from a crashing window (as you rightly identified Stephen). Turns out it was a legacy retain/release issue that none of Xcode's diagnostics was catching.
I inherited an old graphics framework that doesn't use ARC. It declares ivars like this:
#interface ColourFiller : NSObject
{
NSColor* m_PrimaryColour;
NSColor* m_SecondaryColour;
}
...
#end
then sets them like this in its init method:
m_PrimaryColour = [NSColor colorWithCalibratedRed:1 green:1 blue:1 alpha:1];
m_SecondaryColour = [NSColor colorWithCalibratedRed:0 green:0 blue:0 alpha:1];
Note the lack of manual retain.
So I added one, and all is well:
m_PrimaryColour = [[NSColor colorWithCalibratedRed:1 green:1 blue:1 alpha:1] retain];
m_SecondaryColour = [[NSColor colorWithCalibratedRed:0 green:0 blue:0 alpha:1] retain];
I have no idea why Xcode wasn't flagging this, or indeed why all previous builds/xcode versions were running fine. This code has happily existed without symptoms for years. Some library changes must have been made by Apple in Xcode 9 that finally exposed it.
Thanks again for your help - I can now progress to Xcode 10 and Mojave.
I'm looking at an Objective-C sample project at:
https://developer.apple.com/library/mac/samplecode/FunkyOverlayWindow/Introduction/Intro.html
I don't understand how main.m passes control to the other classes/objects.
Let me explain what I'm trying to do. I'm trying to build that app, step by step. My first step was to get main.m to compile. I believe this is the starting point for most applications. I don't know what to add/compile next, because main.m does't mention/refer to any of the classes in that project.
Any ideas?
The entry point in Objective-C programs is the function called main(). See the following code from main.m
int main(int argc, char *argv[])
{
return NSApplicationMain(argc, (const char **)argue);
}
The main() function begins by calling a function named NSApplicationMain() that is cocoa framework function and not shown to user, which is functionally similar to the following:
void NSApplicationMain(int argc, char *argv[])
{
[NSApplication sharedApplication];
[NSBundle loadNibNamed:#"myMain" owner:NSApp];
[NSApp run];
}
Thus, [NSBundle loadNibNamed:#"myMain" owner:NSApp] is called by NSApplicationMain function and in this time, #"myMain" is identifier for Main Interface(as MainMenu.xib within sample source)
finally MainMenu.xib is run, and then OverlayWindow that is main window of MainMenu.xib will be run.
I appreciate, and understand perfectly, how you could not want to use Xcode - especially if, like me, you come from a Unix/GCC/Makefile environment. However, there are some things that are really quite hard to do without the Xcode GUI and linking buttons and widgets to your code is one of those things.
In Xcode, you click the button in your user interface and drag a line to the code attached to it - these are called IBOutlets and IBActions. So, my first suggestion is to Google those two terms.
Secondly, I recommend you watch this video on YouTube to understand what the XIB/NIB is and how to link it to your code and then you can try and do it without Xcode once you get the concept... video showing linking buttons to code.
Hei.
These two pictures below show what changed. Here's my code for it and the code didn't change.
- (NSString *)tableView:(UITableView *)tableView titleForFooterInSection:(NSInteger)section
{
if (section == 0) {
return #"If enabled, closing apps via the app switcher won't actually close the app itself.\n\nThis option is perfect to use with Fast Freeze.";
}
NSString *offDescription = #"OFF\nDisables the backgrounding capability completely. The app has to restart every time you close it.";
NSString *fastFreezeDescription = #"FAST FREEZE\nThis mode is similar to what 'Smart Close' by rpetrich did. Usually an app has up to 10 minutes to perform tasks in the background before it gets suspended in memory. Since this can be an unnecessary battery drain, Fast Freeze will suspend the app right after you close it.";
NSString *nativeDescription = #"NATIVE\nThis is Apple's built in way of backgrounding.";
NSString *unlimitedNativeDescription = #"UNLIMITED NATIVE\nThis background mode allows apps to execute background tasks for an unlimited period of time, so the app won't get suspended in memory after 10 minutes.";
NSString *foregroundDescription = #"FOREGROUND\nForeground tricks the system into thinking that the app wasn't closed and is still running in foreground. This is the perfect way to continue to listen to internet streams or videos while using another app.";
return [NSString stringWithFormat:#"\n%#\n\n%#\n\n%#\n\n%#\n\n%#", offDescription, fastFreezeDescription, nativeDescription, unlimitedNativeDescription, foregroundDescription];
}
Here are the screenshots:
This is the view before (iOS 8), notice that "\nOFF\nDisables ..." has the gap to the last UITableViewCell like it should be.
This is the view after (iOS 9), the gap is off. Too much space there.
So, does anyone know why this happens? If anyone has an fix or something, please tell me!
Thanks in advance!
This seems like an Apple's bug (iOS 9.0 - 9.1), the more lines footer has, the bigger misplacement gets.
You can even reproduce this in the storyboard using static table view.
I cound't find any workaround yet, the best advice I can give is to file a bug report to Apple.
Update
The bug in storyboard seems to be fixed in Xcode 7.2 beta 2. However this issue still persists when you run the app even on iOS 9.2 simulator.
Update 2
Narrowed down the reproduction of this bug. Basically something breaks after your app presents a table view section header. Check this repo for details.
I have iOS 6 application that consists of UIView with many UIButtons (like 9 to as many as 100) displayed at same time; all buttons are movable, so I'm changing button's frame property all the time.
After using the application for a couple of minutes (= moving buttons around the parent UIView), app slows down. It is very strange also that it seems buttons that are near the bottom of the screen (= parent UIView) are much slower than those on the top of screen.
All buttons belong to same class, inherited from generic UIButton.
It happens only on real device, not iPhone simulator.
Any idea about the issue? I'm using NSlog frequently through the code. Can this be the problem?
Thx,
DJ
You can set your NSLogs to be only in DEBUG mode, it will be much faster in Relese:
#ifdef DEBUG
NSLog(#"log");
#endif
Yes you are right.
Never give NSLog or DLog in release versions..
remove all nslog, or for testing purpose just comment them out.
#ifdef DEBUG
NSLog(#"log");
#endif
or
#define NSLog //NSLog
Also you should check for zombies and memory leaks.
How to view XCode( assembly code equivalent) at the break point?
I have gone to Thread1 and it shows objective-c for the [ViewController viewDidLoad] and then assembly for [UIViewController view] and [UIWindow makeKeyAndVisible]. I want to be able to see the assembly for [ViewController viewDidLoad] with the marker at the break pt?
(Product->GenerateOutput->Generate Assembly File: doesn't show the break pts.)
thx
void addme(int *a)
{
*a += 0xFF;// <-- I want to see the assembly for this: should see an instruction "ADD" in the assembly break down
*a += 1;
*a += 2;
}
- (void)viewDidLoad
{
[super viewDidLoad];
int a = 12;
addme(&a);
}
Steps:
Put breakpoint where you want to see the assembly code
Run program
Once program pauses hit the button that looks like ->| (but pointing down)
Repeat step 3 a lot
Dance
See the world
Wonder at the joys of life
Pop bottles
Grow old
Die
I'm not quite sure this is what you're asking for, but I just did it (well, steps 1-5 & 8) and it worked for me.
It's at the bottom of the screen, above the console.
And it's also likely that you won't see an assembly ADD instruction at all, since compile time constants are calculated and thus optimized away by the compiler at compile time.
#jdl At the matter of fact i don't know Objective-C and #Dustin doesn't know asm... As i understood viewDidLoad function will execute a code in it when some object is loaded. In my opinion you can compile only that part of code which you included in your question and look into assembly code via IDA pro for Mac OS or some other debugger.