I'm looking at some assembly stuff. So, pushl bar is the same as subl $4, %esp movl bar, ($esp).
Few questions:
1) What is special about the %esp register?
2) What does the parenthesis around the register mean?
3) pushl bar would meaning having bar on top of the stack, right? So what is happening when I do subl $4? Does that mean I am creating am empty space on top of the stack for me to move bar into?
ESP is the stack pointer - it always points to the "top" of the stack
The brackets mean "the memory pointed at by" ESP rather than the ESP register itself
You are moving the stack pointer down by four bytes (the stack grows downwards in most implementations - pushing something onto the "top" of the stack means storing it at a lower memory address)
Related
I have a window and a window controller which opens when the user clicks a button.
Sometimes I get EXC_BAD_ACCESS(code=1, address=0x0).
0x7fff6f2a59e0: movq (%rax), %rdi
Here is the code:
ChooseProceduresWindowController *chooseProceduresWindowController = [[ChooseProceduresWindowController alloc] initWithWindowNibName:#"ChooseProceduresWindow"];
[NSApp runModalForWindow:[chooseProceduresWindowController window]];
The error appears then runModalForWindow: is called.
I don't get this error every time, but I couldn't find a pattern.
Thanks
the best way to debug EXC_BAD_ACCESS errors is to use NSZombies.
Check out this video for an explanation :
http://youtu.be/LQtPr8bkB3g
NSZombie keeps all your objects in memory when you are trying to release an object that has already been released, so you get closer to finding your bug. As #Mark H said, it is a memory management issue.
Also you could put an NSLog in your dealloc method to have a better idea of what is getting deallocated when at runtime.
That error will be thrown when the object doesn't exist in memory. I'd start looking for memory management issues. The first would be to make sure you are releasing the ChooseProceduresWindowController after using it.
I really can't figure out why I have this bug.
First of all the debugger stop at machine code
The thread also shows nothing. The program stop at no code actually
So it has something to do with _dispatch_worker_thread
What is that?
Any way how I can debug this? Should I just rollback?
This kind of crash will happen when you are running a (vector)extension which is not supported on your CPU.
For example, in xcode 5 under "project-settings / build-settings / Code Generation, set the
"Enable Additional Vector extensions" to "AVX2". Build your executable.
Now run it on an:
Intel Core i5: it's going to crash (wherever the compiler decided to use avx2) with 'exc_i386_invop subcode=0x0'.
Intel Core i7: it will work.
EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP) is the by-product of a __builtin_trap() - which is a GCC and clang intrinsic function. On x86 it we get
0x4dfa2: movl %esi, (%esp)
0x4dfa5: movl %edx, 4(%esp)
0x4dfa9: movl %eax, 8(%esp)
0x4dfad: calll 0x110ffa ; symbol stub for: objc_msgSend
0x4dfb2: cmpb $0, %al
0x4dfb4: je 38
-> 0x4dfba: ud2
0x4dfbc: movl -32(%ebp), %eax
The instruction ud2 is the culprit here, and is not handled specially by Xcode.
On ARM we this compiles into trap and results in a trace break-point in XCode. Is this a bug in clang we have here?
Ultimately in the context of the original question, I suspect that the library function that is failing has hit a assertion.
In my case I was adding an observer for contentSize to a UITextView in viewDidLoad and was never removing it. Fixed it by adding it in viewDidAppear and then removing it in viewWillDisappear.
It was so annoying to find out :(
Add observer in viewDidAppear
[self.textViewMessage addObserver:self
forKeyPath:NSStringFromSelector(#selector(contentSize))
options:NSKeyValueObservingOptionNew
context:nil];
Remove observer in viewWillDisappear
[self.textViewMessage removeObserver:self forKeyPath:NSStringFromSelector(#selector(contentSize))];
I'm getting an EXC_BAD_ACCESS with my iPhone app on 0x01ad809b <+0015> mov 0x8(%edx),%edi
I have NSZombieEnabled set to YES but I'm not seeing any class printed out in the debugger like I normally do.
Is there another way to debug this problem?
You have a crash caused, most likely, by corruption of memory, using a variable that isn't initialized, and/or casting a non-object type to an object.
First, post the backtrace of the crash. That will provide more context.
Second, try Build and Analyze. Fix any of the problems that it identifies.
Finally, if this is a new crash, go back to a revision right before the crash and then roll forward until you hit the crash. What are the changes made over that span of time?
With more context -- the crash log, in particular (or backtrace, at the least) -- more specific debugging techniques can be offered.
You can select Breakpoint navigator and add breakpoint on all exceptions. Maybe it will help.
Try with malloc info as well.
Use Instruments to Profile and detect zombies instead.
Change the build target to the Simulator
In the Build menu, select Profile
Instruments will open, then select the Zombies instrument
This automatically sets up the NSZombieEnabled flag and will popup a message whenever a dealloced object is messaged. Clicking the disclosure will show the memory management events of the object.
I've been having trouble debugging an iPhone app that crashes in a reproducible way.
Short story:
A custom UIViewController is allocated and pushed onto a UINavigationController's stack.
Some time later the UIViewController is poped from the stack.
The very next push of a UIViewController onto the stack crashes the app.
The standard procedure for any crash is using the Instruments with NSZombie enabled.
Upon inspection of the object's history some is revealed that I fail to understand:
the object receives 2 (two) autorelease messages and
the NSAutoreleasePool's drain method send 3 (three) release messages
So far, the only way to prevent crashes is to NOT send 1 (one) release message to the object in question and thus raising a red flag for memory leaks, only that it doesn't leak.
Is there any other solution that I've overlooked?
Update: As one of you pointed out the obvious:
You have a problem in your code. Nothing to do with autorelease pool drain.
It turned out that the first UIViewController was passed as a delegate to the UINavigationController hence my confusion when the Zombie call was coming from the navigation controller itself.
I should me more careful next time before asking the wrong question.
I'm trying to understand the Leaks Instrument Tool that Xcode4 provides us. The screenshot below shows me a couple of leaks (I think). I was wondering how to read the Leaked object and diagnose where the leak is coming from. Anyone have any suggestions to what [NSPlaceholderMutableString ...] is? I don't have this declared anywhere in the program itself.
NSPlaceholderMutableString is a private subclass of NSString, which is a class cluster.
See that small little arrow in a circle? Click it couple of times and you'll get to the code (if it's yours). (Last time there will be no arrow, just double-click the row)
Read carefully what the titles of the columns and navigation bar say. All info you needed is there ;)