I encountered a crash in my app. It's not 100% reproduce rate crash. From the crash log and dSYM, I can get the point where the crash happened in the line of some cpp file. But most of time the app run well. So I don't know what cause it crash. Can I got more infos in the line of cpp where it crash,like some value of varible in this line when the app crash and so on. Any suggestion is welcomed. Thanks!
Your crash log should have information about the state of the registers in it and that can be quite useful. Beyond that, though, you can't recover state of the running app from just the crash report.
Sporadic bugs such as this can be the most difficult to hunt down.
First of all I suggest taking a close look at the code? e.g. Is there a de-referencing of a pointer on this line. Does your crash log indicate that the error occurred before or after the tread returned to the run loop? Can you surround this crash line with an exception and log the state in the catch block?
It will help if you post the code which causes the crash!
Related
I've received a crash report in Crashlytics that seems nonsense to me; only based of a few characters and method name my guess is that it's somehow related to a model inherited from Realm Object.
Could you please give any clue what's going on here?
why Crashlytics was unable to provide line numbers? (while there's been no issue with other crash reports)
It's showing you where in your code the crash is occurring. It gets a bit tricky with these crash reports in Swift because you don't get exact line numbers, but you do get the closure number. It looks like the easiest place to start is BaseDao.swift at line 41, follow that closure to FavViewController's reloadItems function and check what's happening to the LeafBriefModel object?
We'd need to see more code to fully be able to help, but that should be a start.
I have an application & I am debugging that after some time I am getting below message in console logs
Message from debugger: Terminated due to signal 3
Program ended with exit code: 0
Can anyone help me in telling about this signal 3 log & how can I get rid of this?
Can anyone help me in telling about this signal 3 log & how can I get rid of this?
You'll generally also get a stack trace and probably a lot of other information. You may need to scroll in the console to see it. The stack trace will show you what methods were executing at the point when the crash happened, and there's typically also some indication of what kind of error occurred.
This could have several issues, but probably it will be a memory issue. Try to use Instruments to cover that problem.
Ctrl-click on our Xcode Icon in the Dock
Open Developer Tool
Instruments
Select Leaks (or at least Allocations)
Select your app and start the measurement
My code is unable to build on xcode 7. What is Segmentation fault?
A segmentation fault happens when your code tries to access memory that it isn't allowed to access. This is often a sign of an uninitialized reference.
It's not clear to me from your screenshot exactly what is going on, though. Perhaps you could provide more details?
From the screenshot it looks like it is happening when you build your project. If this is correct, you need to create a minimal example that displays the problem i.e a code fragment that crashes the compiler in the same way and then you need to raise a bug report about it with Apple (supplying your minimal example so they can reproduce it).
This has happened to me a couple of times in the past and the way I have identified the bit that crashes the compiler is to comment out everything in the source file and then add it back in function by function.That will narrow the problem down to the function. After that you repeat with the lines of code in the offending function, until you get the line that crashes the compiler.
Along the way you may find a work around to stop the compiler crashing. If you do, do not be tempted to skip reporting the bug to Apple. They need to know.
When I crash (for reasons I understand; that's not the problem) when I try to do something Cocoa isn't okay with, such as calling a method that doesn't exist or attempting to insert nil into a set, the debugger shows the stack from main() to __pthread_kill, without any of the frames that were present when the actual crashing code ran. There is a frame (9th from main) called objc_exception_rethrow. This leads me to believe that Cocoa Touch is trying to do something or other to recover all exceptions and die gracefully or something. However, it is very irritating when debugging to not have the ability to actually use Xcode4's debugging tools to investigate the calling stack frames, or even see where in my code I crashed.
Is there some way to make the objc_exception_rethrow behavior not happen, and just crash as soon as an exception is raised? Perhaps there's a debug setting that makes it crash earlier (at the right time)? (I haven't messed with any of the build settings in this project yet.)
I don't know any Xcode setting that could disable re-throwing exceptions. To my knowledge they are re-thrown by the runtime. You could try running the app without the debugger attached and let it crash. The crash report should contain a section "Last Exception Backtrace" which will give you exactly what you need in this case.
I found the answer: set a breakpoint on Obj-C Exceptions. It will go to the debugger when objc_exception_throw is hit, which is good. Unfortunately, this happens before the exception is printed, but we can make that happen anyway (most of the time) by setting the breakpoint's action to be (Debugger Action) po *(id *)($ebp + 8).
Is there an easy way to find out what line an app crashes on? The console gives little or no help to help me track down this bug and I would just like to know which line it crashes on.
Thanks!
The easiest way is to run the app under the debugger. When it crashes the debugger will show you what line of code crashed.
If you are throwing an exception rather than actually crashing, you can put a breakpoint on objc_exception_throw using the gdb console window - "br objc_exception_throw".
Are you using xcode? It should give you a visual representation of where you are in the code.
Please post the error you are receiving. The first thing to try is adding some breakpoints. For bad access errors, you can also get a more pin-point analysis from the compiler if you use NSZombie.