I've added PLCrashReporter to my OS X application and am successfully saving the crash dumps to a server. However, plcrashutil does not appear to symbolicate even with the .app and .dSYM in the same directory as both plcrashutil and the crash file.
I also tried following the instructions in TN 2123 for using gdb to get the address and it fails to give a source line for the symbols reported in the crash file.
plcrashutil does not symbolicate, it just creates a crash file in the standard format. You'll need to use symbolicatecrash.pl from Xcode to symbolicate the report.
There is a patched version of symbolicatecrash.pl, which fixes a few bugs, available here: https://github.com/TheRealKerni/QuincyKit/tree/develop/server/local
Please note, that PLCrashReporter currently does not work correctly on Intel 64Bit architecture!
But a new version with support for 64Bit is being worked on from the PLCrashReporter developers in cooperation with HockeyApp. See http://www.mikeash.com/pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html and http://www.hockeyapp.net/blog/2012/4/27/mac-os-x-sandbox-support-is-coming.html
Related
Im trying to get crash symbolication to work on Xcode 7. My app is already on the Mac App Store and I'm getting crash reports. The problem is that they are not symbolized. When uploading to itunesconnect I did check the option to upload the DSYM files.
If you notice on the screenshot below, the first 2 lines are indeed symbolized, but they belong to one of my frameworks not the main application. The main application is giving me a 0X10093d000 symbol repeatedly.
What could be the problem?
[Update: Still don't have all crashes symbolicated in 7.3, but for each crash condition, we can usually page to an individual crash report which is symbolicated]
Try XCode 7.3
For reasons unknown, we can only reliably symbolicate our latest production release with XCode 7.3, even though we didn't use it to create the release.
7.3 introduced some new errors and warnings, so if you do download it, I recommend you download it from Developer Center and install in a seperate directory which does not overwrite your current XCode 7.x install.
I am new to mac and cocoa development. When a cocoa app crashes there is a windows that asks the user to report crash log to apple. I want to write a customized reporting component. So I want to know if crash reports /log are automatically stored somewhere are these simple text files or core dumps ?
I am looking to support 10.5 to 10.8
Crash logs can be found in a number of places.
In MacOS 10.8 (and I believe also 10.7) crash logs would be "~/Library/Logs/DiagnosticReports" or "/Library/Logs/DiagnosticReports" (the first is for crashes for user apps and the second is for system-wide apps).
Now instead of "reinventing the wheel", you may want to consider third party alternatives that can generate and return crash reports to you. Wikipedia lists these:
Unsanity developed an Input Manager called Smart Crash Reports, that
patches Apple software to include a "submit to developer" button
within Crash Reporter. Smart Crash Reports only works with Mac OS
X 10.4 and 10.5.
Uli Kusterer wrote UKCrashReporter, which can send the output of Apple's Crash Reporter to a developer the next time the
application is started.
CMCrashReporter is a small opensource framework, which can send the crashlog to the developer (via HTTP POST) and let the user
enter optional details.
ILCrashReporter-NG, a fork of Infinite Loop's ILCrashReporter (which was for Mac OS X 10.2-10.5); current OS support unknown
plcrashreporter Plausible CrashReporter provides an in-process crash reporting
framework for use on both the iPhone and Mac OS X
Google Breakpad, an open-source multi-platform crash reporting system
Having reproduced an elusive bug that crashes my app (running inside the iOS simulator, to be precise), I want to generate a core file for inspection later. On Linux I would run generate-core-file from within gdb, but that command isn't available in the Mac OS X version of gdb.
So, how can I generate a core file from within gdb? There are ways to ask the OS for a core dump of a crashed app, but I fear the app will change some of its state by then. What's the best way to do this?
Thanks!
Unfortunate there is no gcore command in mac osx gdb, but there is a good article about how to generate core dump on osx
Link
In this article there is a downloadable source code to generate core dump, which I have used many times.
MiniDump is a great feature for debugging crashes on Windows, especially because it is small, so it can be sent via crash reports. (Window Error Reporting).
But it seems Mac OS X and other BSD system only supports full core dump.
Is there any mini-dump implementation on Mac or BSD system? Or how does Mac software developer analyze customer's crash reports?
Thanks!
-Jonny
Yes, you can use Google breakpad, which works on Windows, Mac, and Linux. As an added bonus, the file format it creates is the same as the windows minidump format, no matter what platform it's using - so you can apply your current analysis tools to dumps from windows clients.
I've been building a basic Cocoa application with Core Data and Interface Builder, and no extra coding, frameworks, or header files. I sent it to someone to test on their machine (a last-gen G5 iMac), and they got a message saying that their machine couldn't run it. I discovered the switch to compile for PPC, so I built a PPC version of the application to try out, and that produced the following error message:
You cannot use this version of Application on this version of Mac OS X.
I'm running Xcode 3.2.1, Interface Builder 3.2.1, and OS 10.6.2. The conversation with my tester was a bit confusing; at first it sounded like she only had Tiger on her machine, saying Leopard was incompatible (I corrected and said that Leopard should be, it's Snow Leopard that isn't), and then by the end of the conversation she was about certain that her machine was running Leopard, but had already shut it off by then. So I'm not sure which version of OS X is on the offending iMac, but it's the latest version of either 10.4.11 or 10.5.8 (the tester is in a remote location, so I can't verify personally at the moment).
What can I tweak to try and improve compatibility on my tester's machine?
If they're seeing that message, it's most likely because your app has the LSMinimumSystemVersion key (Minimum system version) set in the Info.plist. You should take this key out or set it to the actual the minimum OS X version you support.
Once you do this, you may well run into the next problem. (Probably a dynamic linker error as a result of using a framework or API that didn't yet exist on 10.4 or 10.5.)
The main problem here is that you're sending it out to a system where you haven't actually tried it. If you plan to support 10.4, 10.5, or both, I highly recommend that you find a spare hard drive, partition it up, and install 10.4.11 and 10.5.8. There are many issues that will crop up on older OS's and if you haven't tried it yourself, it's unlikely it will work smoothly on the first try.