Re: Translating offset from crash dump
> corresponds to your code. You might want to get the assembly from each of > lldb and "otool -tV", as each may provide symbolication that the other > doesn't. Hopefully, nearby references to selectors or strings will help you > figure out which line of code the crash occurred on. otool -t -V -function_offsets /path/to/obj/file gives you the requested offsets, too. At least it does in $ otool --version otool(1): Apple Inc. version cctools-877.8 disassmbler: Apple LLVM 7.0.2 (clang-700.1.81) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Translating offset from crash dump
On Dec 19, 2015, at 10:05 AM, Aandi Inston wrote: > > I have a crash dump from a customer. I cannot reproduce the problem, and I > cannot expect the customer to have endless patience to run test versions > etc. The crash dump identifies the crash location as Routine+offset as I > would expect. The problem is determining the source line corresponding to > this (I realise that, due to optimization, the question of source line is a > fuzzy one, but some clues would help). > Anyway, what would you do with a crash dump routine + offset, not > reproducible? Ideally, your release build would still have generation of debug information turned on and it would be collected into a .dSYM bundle before being stripped. You would keep that .dSYM bundle on your system (doesn't really matter where). Then, you could use the "atos" tool or the debugger to query the symbol. With atos, you'd use the -o option to provide the path to the release build of your plug-in (the same build the customer is using). You'd use the -l option to provide the load address or your plug-in, which is listed in the Binary Images section of the crash dump. If you don't have the .dSYM bundle from the actual release the customer is using, you can try building the same code with the same tools and the same options and build settings, except enabling debugging info. If none of the above is possible, you may just have to read the assembly to understand the path from the routine start to the crash point and how that corresponds to your code. You might want to get the assembly from each of lldb and "otool -tV", as each may provide symbolication that the other doesn't. Hopefully, nearby references to selectors or strings will help you figure out which line of code the crash occurred on. Good luck, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Translating offset from crash dump
> On 2015 Dec 19, at 08:05, Aandi Inston wrote: > Anyway, what would you do with a crash dump routine + offset, not > reproducible? Aandi, I would step back and consider that I am over-thinking the problem. I would look at the information I have, which should be my function in which the crash occurred, and the Apple API I called. This should be enough information for me to make a list of things which could have gone wrong in my function, and critically consider each one. I’ve never dived into assembly language to fix a crash. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Translating offset from crash dump
This seems tangential to cocoa-dev, though I am in a callback from a Cocoa method, I don't think the crash is inside Cocoa but my own code. But here's the problem, maybe someone can suggest a better forum. I have a crash dump from a customer. I cannot reproduce the problem, and I cannot expect the customer to have endless patience to run test versions etc. The crash dump identifies the crash location as Routine+offset as I would expect. The problem is determining the source line corresponding to this (I realise that, due to optimization, the question of source line is a fuzzy one, but some clues would help). I have found how to view the assembly code in xcode 6, but there are no offsets. I cannot use the as command on this assembly code because it seems to use a lot of pseudo-ops not understood by as (I don't know if as would give a report anyway). I could hand assemble but I don't know the pseudo-ops either. otool doesn't seem obviously to help. Running the debug version in the debugger won't give accurate offsets. I suspect my best bet might be to load the production product (complication: it is a plug-in, not an app), in the debugger, and examine the routine code, perhaps comparing to the assembly code, but I don't know how to use gdb that way. Anyway, what would you do with a crash dump routine + offset, not reproducible? Thanks in advance. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
