So I need to check if the stack is empty before returning a value that is being calculated.
if its not empty, then I will raise an error.
How can I check if the stack is empty or not?
Compare $sp with null, how?
or if starting address of $sp is always the same, should I hard code it? (if address of $sp equal to 270346..3, then empty) (this feels very wrong)
Any help would be appreciated
Thanks
You should never check if the call stack is "empty" — this concept doesn't really make sense — the call stack is supposed to always be there.
However, if you are pushing a dynamic number of things onto the stack, and later popping them all of them off, you can either:
Capture the value of stack pointer before any of the dynamic pushing, and then as part of dynamic popping compare the current stack pointer with that previously captured stack pointer — when they are equal, there's nothing to pop.
Alternately, start a count at zero before any dynamic pushing, and add to that count as items are pushed, decrement the count as they are popped — whenever the count is zero, then there's nothing to pop.
On the other hand, if you are writing a program that takes control directly from the simulator or from the operating system, these are special in that there is no one to return to. Because of this, usually we use custom startup code for that, and such startup code is not a classic function.
Any code that is written as a function can assume that it was called, and thus can return to its caller.
Related
I have made an iOS Swift application with some ViewController(s) that are not entirely finished, so I haven't provided methods for them to be presented yet.
Is it safe to leave these ViewController(s) unreachable?
Xcode will display a warning stating that the ViewController is unreachable in the Storyboard, but since it is only a warning, it doesn't affect the build process.
Also...
Do I risk getting my app declined by Apple if some ViewControllers are inaccessible?
Is it safe to leave unreachable ViewControllers (I mean, will it cause any crashes or bugs?)
I want to avoid getting rid of the ViewControllers because I will need it in the next version.
Does this differ from leaving unreachable XIBs, and leaving unreachable Swift files that hold the class for the ViewController?
A view controller in the storyboard has effectively no overhead at runtime unless it is actually loaded, at which point it is turned into an instance. It occupies a pair of nibs (one for the view controller, one for its view), which take up some space in the built app; but the runtime never even bothers to look for those nibs if you do nothing that loads the view controller's nib.
A code file for a view controller that is never instantiated has effectively no overhead at runtime. It has some overhead at compile time because the code has to be compiled, so it adds a small amount of time when you build. The compiled code takes up a tiny amount of space in the binary.
Thus I think you can conclude there is no downside to what you're doing.
How does one move items up in the stack?
(Pseudocode, because the code inside and the registers to push will vary.)
push registers to stack
alter the registers
get return value on top of the stack
keep the top of the stack but restore the registers
So the stack looks like this:
(Top)
(Return value)
(Register)
(Register)
...
(Register)
And I want to make it look like this:
(Top)
(Return value)
And then have the registers get their values from the stack. Is this at all possible? I am trying to do it in gas. Can this be done? Thank you in advance.
If I understand correctly, you want to put a return value (which you get from...?) before the registers on the stack, then pop the registers, but keep the return value?
One suggestion I could give is to make room for your return value on the stack first (like subl $4, %esp, in case your return value is 4 bytes) and then put your return value there, instead of on top of the stack.
Another suggestion (which may be easier to implement), is to make some room in the .datasection with .skip, move the return value there, and then after restoring the registers move it back to the stack.
It's hard to give you a concrete example, since I don't know much about the scenario.
I have a quick question- does it matter if the memory that is used by an app while it is running increases slightly (0.1mb) every single time a view controller is loaded? I have a game which has an infinite level, and if the player loses the view controller basically refreshes (e.g. all timers invalidated) and the main menu controller is loaded. Then every time the infinite level is restarted, the memory (shown in the debug navigator) goes up. So the first time the level is played it is 226 mb, the second it is 226.2 mb, third it is 226.4 mb etc. Is this a problem?
What is probably happening is that there are a few strong references to Views/iVars/Properties still left dangling when you release your infinite level view controller (by dismissing/removing from superview). Try to release all your properties and instance variables just before you release your view controller. You could also try to define all your IBOutlets (which don't get removed from the view) as Weak type, so they get released when the view controller is dismissed.
Some points you can remember as a checklist for memory management:
Any property/variable with a strong/retain type should be released by the user. ARC does it automatically, but sometimes it does not release correctly (Don't ask why).
Instance variables are by default a "Strong" reference type, which means you have to release them manually
IBOutlets that remain in the view and you don't removeFromSuperview, can be of weak type, since the view holds a strong reference to it.
(if you do not have ARC on) Make sure that you have an NSAutoReleasePool block so that it releases all local variables, thereby preventing memory leaks.
Your problem, while not serious at the moment, could become serious quite soon. The average iPad/iPhone starts giving memory warnings around 300 MB, so if you start adding any more features to your game, this could become a big problem.
Hope this answer helps.
I have a UITableiew listing n number of contacts and from Table view delegate didSelectRowAtIndexPath I am navigating to a 'Contactview' UIViewController by using UINavigationController pushviewcontroller.
For an instance if I navigate the first contact to Contactview, Live Bytes memory goes up from 1 MB to 3 MB. Then when I tap on the back button the viewcontroller delloc method is called but the memory still stay around 2.95MB to 3MB . My question is when the viewcontroller delloc method is called the memory of the viewcontoller should be released right ? Am I wrong anywhere ? Please suggest me if I am wrong. And I am using ARC project.
Thanks in Advance..
If you push your navigation back and forth and you see memory climbing unlimitedly, you have a memory management problem. Even with ARC, you may have abandoned memory. You can detect it using the Allocations template in Instruments.
In Instruments, put the application in a well-known starting state (for example, showing the table view).
Click Mark Heap button under Heapshot Analysis.
Navigate your controller back and forth once.
You will see a small increase in memory usage in the allocations graph. This is normal, internal caches may be storing some information.
Click the Mark Heap button again.
You will see a number of objects in the Still Live column.
Repeat steps 3-6 many times and see if there are "still living" objects after every iteration.
If there is an almost constant number of still living objects in each heapshot, click the right arrow button in one of the heapshots and you will see all the objects that are still living. Look for objects probably created by you, select one, expand it, and select its memory address with a simple click. Then click the Extended Detail button to see a stack trace showing where the object was allocated. With this code context I'm sure you will understand why your memory was abandoned.
See.. one thing ARC will release it the contents some where in future right.Its Automatic right.. how can expect the ARC to do the Gatrbage collection after class will disappear.It might take time to free the memory.
Did you check retainCount? is that showing your desired value?
UIImage caches images for you as an optimisation, so this is expected behaviour.
If you wish to confirm that this is the case, for peace of mind, you can force a low memory warning (Under the Hardware menu for the simulator). This should get UIImage to throw out its cache.
You can also use this private method, but of course throw it out before submission.
[[UIApplication sharedApplication] performSelector:#selector(_performMemoryWarning)];
You might own a strong reference for the view controller elsewhere in the code. You should be sure if it's really deallocated... If any other object has reference to it beyond the navigation controller it won't be deallocated. Try override dealloc. (You could override dealloc in an ARC project as well, you are only not allowed to use retain count manipulation calls.) To be sure if dealloc is called put some logging or something debugable code into that method.
Edit: While my comments have an iOS 5 working example, I am still getting this for other versions. I've now implememted a test to only register and dequeue cells if iOS 5, but it's really puzzling!
still receiving _accessibilityUpdateRemoveControl exceptions, strange nuisance, appears to be something with the edit controls, nothing is retained so nothing needs deallocing, but will try, and post the answer if I find it!
This was working yesterday, and now it's not... I changed nothing!
Edit: Turns out, while reloadData causes the crash, the crash does not occur without my custom tableViewCell... hmmm, something about removing the + sign, but it doesn't happen with deletion!
Actual error is this:
[CustomTableViewCell _accessibilityUpdateRemoveControl]: message sent to deallocated instance.
What's funny is, the remove button works. Essentially it removes the item from an array, adds it to another, basically putting it "to another table". No crashing, works fine.
If I remove the line that reloads the data in the table, after the insert button adds it, it also works. Eg: Don't immediately reload the data, close window, come back, everything displays fine. The exact line, so far, that crashes it is in
[theTable reloadData], but that line, for the other table (as I update both) doesn't crash at all. Actually, thanks to that, I'm gonna view the headers for UITableView's functions, and view other answers with that specific line. I just didn't see this, anywhere, after searching for that weird function call.
I'm ensuring my cell is within memory, and even quit dequeuing just to ensure it's working. I'm stumped with this, hopefully will have solution in an hr or less.
Thanks
I stepped through Apple's code, line by line, read the name of every function and noticed this:
editControlWasClicked: (id) clicked
is called just before crashing. I combined that with the error message, and the fact I call [table2 reloadData] before this is called, and pieced those pieces together.
The cell is erased (so it moves to the other table), but somehow calls its system callBack "editControlWasClicked" after the table reloads... since it's on the main thread, I'm guessing the table stuff is multi-threaded... how else would it call these in order but do that After the reload??
So to test this, I used the "afterDelay" function, and low and behold, it worked.
You may be asking why I'm using an add edit control in one and subtract in the other... there is a purpose to that.
So, possible solutions: 1) use the afterDelay method of selectors.
2) Write a custom IBAction ('cause it's a xib) or otherwise use custom images and functions to ensure that doesn't get called back.
Note, 2 involves writing an extra delegate so that messages from the cell can reach the view controller.
Basic solution: use iOS 5, use the queuing, otherwise do one of the above solutions or figure out the threading/hooks and find a way to do this without delaying. (I would prefer such if I can find it)