I have a minidump of crashed application and I would like to analyse it using DbgEng in my own library. Does anyone now how can I get the stacktrace of the thread that caused the program crash using IDebugControl::GetStackTrace?
I appreciate any kind of help
Thx
Depending on how the crash dump was generated, it might be using embedded contexts. Use the IDebugControl4 interface which gives you access to the GetStoredEventInformation and GetContextStackTrace methods. If GetStoredEventInformation fails, you can fall back on the GetStackTrace method.
The solution is described in this article http://blogs.msdn.com/b/joshpoley/archive/2008/11/10/minidumps-and-bad-stacks.aspx
Related
i used Bugsense framework in iPhone application to get the crashe logs, and it works fine.
but when i get the crash report from iTunes account, the crash report indicate that there is a crash in bugSense framework.
What this is mean? is it indicate that crashes in applications reported by bugSense ? or it is actual crash in the framework itself?
Please Help.
Thx
It could be, that this is a crash in their SDK. Sadly they perform non-async safe functions in their framework once the crash happened. See http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html for more details on what that means (in this case calling Objective-C code once a crash occurred is unsafe). You might want to contact them to make the fix this possible problem.
But the messages lower in the stack trace also indicate, that this is a crash that happened because of an uncaught exception occurred, which would normally cause another Last Exception Backtrace to appear on top of Thread 0. I am not sure if they have that functionality included. If they do, this causes that block only appear in their own crash report but not in the crash reports iOS creates. Then this is nothing to worry about, except that code above being bad as already mentioned.
If you have enabled immediate dispatch in BugSense, this is probably the reason of this crash, as it isn't guaranteed to be safe.
For more info you can check this: https://github.com/bugsense/plcrashreporter-bugsense/wiki/Using-the-BugSense-2.x-iOS-library , section Enabling immediate dispatch
this may happen when there is no internet connection, try enable immediate dispatch in bug sense
Recently my iphone project comes to the end, but suffer some random crash during app running, and the call stack is always located in COCOA library, tough issue, don't know how to deal with it, for some cases I even suspect that is it apple's defect?
My questions.
For those random crash issue with few reproduce rate, how do you guys handle it? Any method to help to increase reproducible rate?
How to fix these crashes located in COCOA library? How to find more clues?
Any idea or discussion will be appreciated, thanks in advance.
If the app crashes in the COCOA code it does not mean that COCOA code is wrong - much more likely you fed some invalid data to it (for example nil where it does not supposed to be). If it's happening randomly there might be some multithreading concurrency behind or some of your objects become (auto)released too early, etc. You have to carefully analyze your code which operates with the COCOA classes where your crash happens, or try memory management debugging as suggested by other answerers.
Generally, I don't start thinking that is COCOA the problem. It happens, but most cases the fault is ours.
When this kind of crashes happens the first thing to do is to run the static Analyzer, sometimes it's just a retain/release problem.
If you're using ARC, skip this part and start creating an Exception Breakpoint (search 'To add an exception breakpoint...' in linked guide). The exception breakpoint helps to have a more detailed crash log when an exception is thrown.
The third step is using Instruments, looking for waster memory, leaks and any other form of memory drain. How to use Instruments is deeply explained in a couple of WWDC videos.
Enable NSZombie flag.
project(On Top LeftCorner of xcode)>Diagnostics>enable zombie objects
It will lte u know where ur code is crashing ..find it fix it
I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.
Does anyone knows how to simply access the log?
Thanks,
Guy.
I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.
It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:
http://www.cocoadev.com/index.pl?SignalSafety
Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.
It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:
http://code.google.com/p/google-breakpad/
On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.
I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do.
Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.
Eventually, I used the following example:
http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
it's very simple and easy to use, just register exception and signal handlers using:
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
and get the stack trace using the backtrace method in UncaughtExceptionHandler class.
Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.
Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by #nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.
There are a bunch of (SAAS) E2E solutions that you may be very happy to know.
Very very simple to integrate into your application
Have Fun...
crashlytics (Free and my preferred)
hockeyapp
bugSense
Crittercism
In our days you may use the built-in crash reports (iOS & Android)
iOS (Itunes connect) - Viewing Crash Reports
Understanding Crash Reports
on iPhone OS
Reading Android Market Crash Reports
I have a piece of code that uses NSURLConnection to fetch a network resource asynchronously and parse some XML as it streams in. The XML parsing is handled by libxml2 which is available as a framework in the iOS SDK. This works perfectly when I invoke it once, parse the XML and release the resources by calling xmlFreeParserCtxt(ctxt).
My problem is that when I run this same code in multiple threads, all of a sudden i see EXC_BAD_ACCESS pop up which I trace back to the libxml2. Specifically the xmlParserCtxtPtr context which is initialized and used for XML parsing seems to throw the EXC_BAD_ACCESS when I release it after I am done retrieving the resource.
The exception goes away if I do not release this context i.e. call xmlFreeParserCtxt(ctxt).
This leads me to believe that my issues are some how related to libxml framework available in iOS not being thread safe.
Sure enough, I see this when I google the issue:
From: http://xmlsoft.org/threads.html
Starting with 2.4.7, libxml2 makes provisions to ensure that concurrent threads can safely work in parallel parsing different documents. There is however a couple of things to do to ensure it:
* configure the library accordingly using the --with-threads options
* call xmlInitParser() in the "main" thread before using any of the libxml2 API (except possibly selecting a different memory allocator)
So I have two questions:
1.) Is my assumption correct that the version of libxml that I am using is not thread safe and hence causing the issue? Has anyone else seen this?
2.) I know that the iOS bundles libxml2.2.x - would it work if I get libxml2.4.7 and add it to my project? Would that cause any rejections on the app store?
Thanks for your time.
I'm working with an Objective-C wrapper around SQLite that I didn't write, and documentation is sparse...
It's not FMDB. The people writing this wrapper weren't aware of FMDB when writing this code.
It seems that the code is suffering from a bug where database connections are being accessed from multiple threads -- which according to the SQLite documentation won't work if the if SQLite is compiled with SQLITE_THREADSAFE 2.
I have tested the libsqlite3.dylib provided as part of the iPhone SDK and seen that it is compiled in this manner, using the sqlite_threadsafe() routine.
Using the provided sqlite library, the code regularly hits SQLITE_BUSY and SQLITE_LOCKED return codes when performing routines.
To combat this, I added some code to wait a couple of milliseconds and try again, with a maximum retry count of 50. The code didn't contain any retry logic prior to this.
Now when a sqlite call returns SQLITE_BUSY or SQLITE_LOCKED, the retry loop is invoked and the retry returns SQLITE_MISUSE. Not good.
Grasping at straws, I replaced the provided sqlite library with a version compiled by myself setting SQLITE_THREADSAFE to 1 - which according to the documentation means sqlite is safe to be used in a multithreaded environment, effectively serialising all of the operations. It incurs a performance hit, that which I haven't measured, but it ridded the app of the SQLITE_MISUSE happening and seemed to not need the retry logic as it never hit a busy or locked state.
What I would rather do is fix the problem of accessing a single db connection from multiple threads, but I can't for the life of me find where it's occurring.
So if anyone has any tips on locating multithreaded bugs I would be extremely appreciative.
Thanks in advance.
I haven't tested this to see if it works, but you could try wrapping access to the db connection in a function and then using Instruments to log accesses to that function which, IIRC, should let you get a thread ID and a stack trace. That should give you a bit of a handle on where it's coming from. Alternatively you could just set a breakpoint on it but that might take a bit longer.