I got an EXC_BAD_ACCESS in my iOS program, and I suspect that the cause is in one of my anonymous blocks, but there are quite a few of those, and I need to narrow down the candidate list a bit.
The stack trace shows the current frame as __lldb_unnamed_function4866$$ProjectName. There are no line numbers or source file names that I can see. No local variables visible either. The debugger shows machine code instructions. This was running on a background event queue, so there is none of my code anywhere else on the stack.
How do I go about finding out what function this is?
I came across a similar situation, and while I can't help (yet) with your problem, I think I know a man who can.
Check out http://www.realmacsoftware.com/blog/block-debugging, for an exposition of how to find out a lot more about the evil block in question.
It doesn't help me much, because I'm working from a crash log, but if you're still interested, this is going to give you just about as much as you can get about the unnamed block.
Warning, the above link exposes you to a lot of arcane knowledge, and may make you feel a little inadequate :)
[Editted to add]
Not good enough yet?
After searching through disassembly and doing some manual symbolication, I came to the conclusion that the ___lldb_unnamed_function is a red herring.
I followed How to manually symbolicate a crash log with atos, and it pointed the finger at a completely different function, which came from a 3rd party library, and was a very good candidate for the crash reason (killed by angry watchdog with badf00d.)
In the course of this enquiry, I also came across hopper, a great disassembler; I used the demo version to confirm what the suspicious code was doing, so I'm giving them a namecheck.
Try to set an exception breakpoint by clicking on the plus symbol within the breakpoint navigator cmd + 6.
For getting an overview of debugging best practices if found it useful to consider a Stanford Lecture on iTunes U
Related
Working from the tutorials I wanted to try PID-controlling a second order linear system. I'm running into segfaults when simulating the closed loop. I've put my code over on Gist. It is mostly identical to the example in the dynamical systems tutorial.
Here's what works
Simulating a diagram containing only the second order system
Dropping in PendulumPlant for the second order system and using the controller
Every step up to simulator.AdvanceTo - that's where the segfault occurs
I'm sure I am missing something obvious here. Does anyone with more experience see what's wrong?
Thanks for reporting this. I didn't see anything on quick inspection. I ran your code (both on linux and mac) and was able to reproduce. Absolutely you should never see a silent segfault, so this is a real issue.
I've escalated it here: https://github.com/RobotLocomotion/drake/issues/12497
FTR - I've also opened a PR to improve the PidController documentation. https://github.com/robotlocomotion/drake/pull/12496
I'm investigating this now -- I've also successfully reproduced the bug locally using the provided python, but I've also reproduced it directly in C++. [Reproduced in now defunct branch]
I'll update when I have something concrete.
Update 1: You've got an algebraic loop in these two systems (one that does not exist for the PendulumPlant as its derivatives and output are expressed in terms of its state and not its inputs). In this case, both systems' outputs depend directly on their inputs so, kablooie! The bug, in this case, is figuring out why that isn't communicated to you right up front.
Presumably, you'd also like to know what the right version of this program is that doesn't have an algebraic loop. Stay tuned.
Final update
A patch has gone through to correct the underlying bug. Depending on how you're accessing Drake, it's immediately available in master, or you can wait for the next binary (as to your taste).
Thanks for bringing this issue to our attention.
TraceGL is a pretty neat project that allows JS programmers to trace code paths in Javascript. It looks something like this:
I'd like to build something similar for Objective C. I know the runtime has made it rather easy to trace method calls, but how would I trace control flow? For example, in the screenshot above, code paths not executed are made obvious with a red highlight. What would be the best way to achieve something similar in an Objective C/Xcode workflow?
The best I've come up with so far is to write a preprocessor that injects code into temporary source files before sending them to the compiler. Anyone have a better idea?
I guess the visualizer for issues found by Xcode's static analyzer comes pretty close to this - albeit this one will only give you the call path for a particular issue like a memory leak.
Try "Product > Analyze" in Xcode, select any of the issues found on any given project and click on the blue arrow in the code editor to see for yourself.
Not exactly answer for Objective C and XCode.
For C++ code there is a industrial quality code coverage tool BullseyeCoverage
Function coverage gives you a quick overview and condition/decision coverage gives you high precision
Works with everything you can write in C++ and C, including system-level and kernel mode
If you want to invent/write this kind of tool yourself I'd recommend to take a look at (evaluate) some existing tools that solve the same task so that you don't miss a key functionality
There are basically 2 categories of such tools
working at binary level, instrument byte code, library entry points etc.
working at source level, instrument source code before going to the compiler
The purpose of the instrumentation is to insert into the code calls to a profiling runtime that collects the runtime statistics for further processing.
Basic calls
timestamp, thread id, source code address, entering
timestamp, thread id, source code address, leaving
The source code address depends on the granularity you are interesetd in. It can be a function name ot it can be a source file and line number.
Collected performance data can be quite huge so they are usually summed-up and whole callstacks are not captured. It is usually sufficient level of detail for detecting performance bottlenecks.
Another drawback is that capturing detailed performance data especially in code points with many hits will slow the application significantly.
If you want complete history then capture the full trace including timestamps and thread-ids and you will be able to recreate the call stacks later knowing that each enter has corresponding leave.
To guarantee this pairing the code instrumentation must insert exception handling calls to make sure that exit point will be logged even if the function throws an exception (what is the "exception" and how to try-finally it dependes on the language and the OS platform).
To get all necessary tricks and tips evaluate some tools and take a look at their instrumentation style.
BTW: in general it is quite a lot of work to do and to get right I'd personally thought twice or more times about what will be the outcome and what will be the costs.
As a want-to-play-with topic I fully recommend that. I created such a tool for troubleshooting Java MIDP applications working at C++ source level and Java binary level and it was helpful at the time when we needed it.
We've just released an app using the Crittercism framework. After some time, we've had about 125K app loads, and 95 crashes - a rate of less than 0.08%.
One crash happened 19 times, another 10, but the other 41 all occurred 3 or less. If there were any major problems with the app, I would expect to see significantly more failures in particular areas, so I'm happy with the level of figures I'm seeing.
A quick look shows many of them to be low level failures, not obviously caused but programmer error.
Examples
The largest group are all to do with CFNetworking on a background thread while static HTML is being being rendered in a web view on the main thread.
There are some KVO failures in free_list_checksum_botch
But my question is, in a sufficiently complex OS (iOS in this case), with a sufficiently complex app (which I think it is), should I, as a developer, expect to see this level of "background noise"?
Should I expect to see one app crash per 1-2000 loads, just because the OS isn't perfect? Has anyone else had a similar experience?
(I'm not looking for solutions to the errors themselves.. thanks!)
Crittercism conducted an analysis on app crashes. Their report was based on Android vs iOS crashes.
They concluded that the most popular apps on iOS crash 0.51% of app launches. So #Ashley Mills, if you're getting 0.08%... you're doing well. (i think I have my figures correct, anyway).
Not sure where the original report is, but I read it here:
Forbes app crash rates, conducted by Crittercism
Actually another shot in the dark non-technical answer could be. What added value will it bring you (the developer) to keep digging into that particular issue, when you could be spending more time and effort either developing more capability within your tool, or another tool completely.
If your app is simply for fun and learning, then I could see digging into this issue as a fun adventure. From a business perspective, what is your time worth and is figuring out this 0.08% problem going to sell enough (more) copies to make your efforts worth it.
An analogous would be, what requirements are essential, and what requirements are desirements?
Just food for thought. I know many of the companies I have worked for don't see the value in stressing about that low of a yielding bug.
I am an iOS developer, employed professionally. I take it personally when my apps crash, because that is not the user experience I was aiming for. A crash is a bad user experience. One crash, per user, is too many. A crash is a bug.
That being said, I have definitely seen crash logs that appear to be unsolvable because they seem to be indicating a problem way down deep in the SDK. What I have learned, however, is that more than likely there is something about my own code that is ultimately the cause.
There are any number of bizarre crashes that can be caused by timing issues between threads or blocks or just because I did something wrong. Just recently I discovered I was doing something entirely wrong with respect to a complex table I was updating. The crash logs for this problem provided almost no clues except for the general area of code I might look at. As I dug into the code and started experimenting, I realized my mistake, which ultimately was a timing issue caused by what I thought was a clever separation of main-thread vs. non-main-thread activity. I was too clever for my own good, in this case. :-)
So, to sum up:
One crash is too many crashes and ultimately a bad user experience.
Often, bizarre low-level crashes are the result of your own code's complexity and possibly timing issues there in.
Finally, I offer this question to consider:
Are you willing to piss off or dismiss some of your users simply because they fall into the 0.08% of users experiencing crashes?
Food for thought. :-)
I'm a professional iPhone developer, and what I've seen is the crash frequency isn't what upsets users, it's the funnel for how the crashes happen.
If they are intermittent you are usually okay, the problem starts to occur when one user experiences a specific crash multiple times. This is unacceptable.
Striving to remove every crash is always a good thing, but in many cases it's simply not realistic, you have to decide where your time is best spent. If you have the opportunity to rework a portion of the UX flow or fix an intermittent crash, you need to decide which one benefits more users.
The important thing to remember is, if you choose not to fix a crash that happens 0.08% of the time, you aren't writing off the users experiencing it unless they are experiencing it multiple times.
Although not a technical answer, on my iPhone I'd personally expect to have an app I use a lot crash at least once or twice over a year. I'd say that level is perfectly acceptable, and since generally I find they crash a lot more on the first time you start it I believe it's something to be expected.
when trying to email contents from text fields im having exceptions thrown. I think im wiring them up wrong.
Im creating outlets for my text fields in .h, setting up my email button as an action.
In .m im implementing usual code for sending email. Ui message frame kit has been imported.
Now I need some help as thats not working for me.
To summarise: How do i email whats in my text boxes?
Im using xcode 4.3 with storyboards
Thanks
There are no tricks to emailing the contents of text boxes. You need help with some exception, you need to provide us the precise error and show us the relevant code. If you want to try to solve it on your own, you should debug the code, single stepping through the method that attempts to email the contents of your text boxes (see Xcode 4 User Guide: Debugging and Analyzing Your Code; see the section about adding breakpoints and then the section about controlling execution).
Exceptions are generally the result of memory management problems (e.g. your code is trying to use some object that has already been released) so you might want to enable zombies if you haven't already. I also think that people do not sufficiently appreciate the value of Xcode's Analyze command on the Product menu (described in the aforementioned Analyzing Your Code section). This Analyze command will identify not only dangling pointers, but also some memory leaks. It's not perfect, but it's a good start.
People really shouldn't be posting questions here if they haven't first resolved the problems raised by Analyze (unless, of course, you need help fixing issues that Analyze raises). Personally, when I went through this Analyze exercise on my first big project, it was painful to clean up all the issues that it identified, but, more importantly, I suddenly "got it". I've been an IT professional for decades, have programmed in dozens (literally) of programming languages, but only after going through this painful exercise did I finally get the subtleties of Objective C memory management. Suddenly, rereading Apple's Advanced Memory Management Programming Guide, it all made perfect sense.
So, if you're still stymied, and the Analyze command did not identify any issues, and you ran the code through the debugger you were not able to identify why the exception was generated, then just provide us a detailed error message and show us the relevant code and I'm sure we'd be happy to help.
I've seen this question posted before but all answers given where fixes to specific code errors that were posted.
I want to know what does "attempting to create use_block_in_frame" actually mean and what can generally be the cause of it.
It's a warning from the debugger itself that it could not create an info struct for a particular object. Basically it's fallout from a previous error.
It's probably a red herring. I'd suggest looking at errors referring to your code (note this one is a warning only) that happened before this and work from there. Figuring out the particulars of this warning is unlikely to help.