I am running a subroutine which will have some implications on the memory occupied in the given time frame and has the capability to crash the app.
I am wondering if there is a macro that can force the app to disable ARC just for that particular block of code in a single file (similar to how you would implement native assembly instructions in a block of code).
Related
Nvwa crashes on free calls in its delete operator overrides, especially on simulator, with error:
malloc: *** error for object [hexadecimal address]: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Your leak detection library apparently and ironically has a heap corruption bug, likely use-after-free. I suggest you use Instruments or malloc history to determine what that address previously corresponded to and then audit the lifecycle of that allocation and pointers to it.
It's all about compilation settings on the target that you use to build the library.Nvwa uses platform-specific macros to recognise available threading libraries and it so happens that _PTHREADS is not normally defined on iOS and I did not allow C++11 mutexes by NOT defining NVWA_USE_CXX11_MUTEX set to 1. So we have few alternatives, either define _PTHREADS, allow use of C++11 mutexes or change Nvwa code to also check for _POSIX_THREADS macro... One of the places that absolutely require "proper" mutexes is the update of allocation list that is used to report leaks (in debug_new.cpp). Without synchronising there, next element pointers are bound to eventually point to released memory and use-after-free is just a matter of time.
We need to reduce the memory consumption of our title, initially for iOS and then later for Android.
One of the areas we're looking at is code stripping as suggested in the article Optimizing the Size of the Built iOS Player.
Testing the various stripping levels, assemblies and byte code, we are experiencing a crash at runtime. I have narrowed this down to using the AssetBundle.LoadAsync() method, replacing its usage with AssetBundle.Load() calls. Whilst this is has stopped the crash, it has severely broken parts of the game that at this late stage we don't have the time to repair.
So, taking a step back - the code stripping is removing a dependency of AssetBundle.LoadAsync() that causes the game to crash at runtime. In the linked article it says to use a link.xml file to specify additional dependencies (I've had to add System.Security.Cryptography to this list).
Q: What are the dependencies required for AssetBundle.LoadAsync()?
Also, are there any tips for working out dependencies? I had a peek in .NET Reflector however that didn't yield much information as it just calls an external DLL.
How can I find out how much memory my App is using from inside the app itself, using MonoTouch?
I basically want this:
Watching memory usage in iOS
which calls things like "task_info"
but for MonoTouch (it's OK if works only on iOS). I don't want a memory tool, like Instruments, etc, I just want to know the memory used from inside the App itself, so I can display it and be able to check it isn't too much in various field trials, etc.
I see at least two options:
Copy the "task_info" code into a new Xcode project and create a static library out of it. Then you link with that static library in your MonoTouch project, and use a P/Invoke to call logMemUsage.
Translate all the "task_info" code into C# (using P/Invokes to call native methods whenever required).
I would likely go for the first option, I believe it's somewhat less error prone.
What is the easiest way to produce a Mach-O object file that does not have the SUBSECTIONS_VIA_SYMBOLS flag set, such that the linker (with -dead_strip) will not later try to cut the text section into pieces and guess which pieces are used?
I can use either a command-line option to llvm/gcc (4.2.1) that will prevent it from emitting .subsections_via_symbols in the first place, or a command-line tool that will remove the flag from an existing object file.
(Writing such a tool myself based on the Mach-O spec is an option, but if possible I'd rather not reinvent the wheel that hard).
Platform: iOS, cross-compiling from OSX with XCode 4.5.
Background: We're supplying a static library that other companies build into apps. When our library encounters a problem it produces a crash report with a stack trace and certain other key information that (if we're lucky) we get to analyze later. Typically the apps as deployed have been stripped of debug information so interpreting stack traces is a problem. If we were making the app ourselves we would just save the DWARF debug data from before stripping and use that to decode the addresses in the incoming crash reports. But we can't depend on the app makers supplying us with such data from their linking steps.
What we're doing instead is to let the crash report include the run-time address of selected function; from that we can deduce the offset between addresses in our linker map and addresses in the crash report. We're linking our entire library incrementally into a single .o before we stuff it into an .a; since it does only one big thing there wouldn't be much to save from removing unused functionality from it when the app is eventually linked. Unfortunately there's a few small pieces of code in the library that are sometimes not used (alternative API entry points for the main functionality, small helper functions for interpreting our error codes and the like), and if the app developer links with -dead_strip, it disturbs the address reconstruction of crash reports that the relative offsets in the final app differ from the linker map from our incremental link operation.
We can't realistically ask all app developers to disable dead-code stripping in their build process, so it seems a better way forward if we could mark our .o as "not dead-strippable" and have the eventual app linking respect that.
I solved it.
The output of an incremental link operation only has MH_SUBSECTIONS_VIA_SYMBOLS set if all the input objects have it set. And an object file produced from assembler input only has it set if there's an explicit directive set. So one can remove the flag by linking with an empty assembler input:
echo > empty.s
$(CC) $(CFLAGS) input.o empty.s -nostdlib -Wl,r -o output.o
I'm trying to optimize the memory usage of an iOS app, and I'd like to see what the app's total memory usage is at specific points in the code. I was thinking I should be able to set breakpoints, profile the app with Activity Monitor, and just look at the memory use when each breakpoint catches. But when I run Instruments, it seems breakpoints no longer stop execution, so it's hard to know exactly when memory usage is changing.
Is it possible to use breakpoints and Instruments at the same time? If not, is there a clever way of writing some code to insert a marker into the Instruments timeline when specific events occur?
I also ran into this issue today, and after a bit of searching I found this solution. Text below is a quote from the post:
Breakpoints Do Not Break. Instruments utilizes debug information from
your debug build, however, it does not stop at break points you set.
This is because while you are loading your application into
Instruments from the menu in XCode, Instruments simply uses the path
of the current executable as its start path and loads it externally
from XCode. The menu in XCode is really there as a convenience
mechanism. This is not a big deal as you can always run again in Debug
mode after your instruments session should you want your application
to break. It’s just something to make a note of.
NSLog Statements Do Not Show In The Debugger Console. If you want to
see your NSLog statements, you will need to load the system Console
application (/Applications/Utilities/Console).
Reference: http://www.cimgf.com/2008/04/02/cocoa-tutorial-fixing-memory-leaks-with-instruments/
Well, you aren't running under control of the debugger.
One approach might be to add alerts at the key points, and take a heapshot then (manually).
Or there may be some dtrace wizardry.