Re: Crash reporter starting stack trace
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rlMnttrjFqKfpPXsfcSgZPdZd7u/LPOZo6gLzZqcmdU=; b=L2VEhV6m08NmN7cN6ZjD3RTbX/6ZvRLjO1G7lljruhQEBcwMoxHgiEXH6/RY3tovTp 16L5qcXMKQuIWFWIstyYUrh8lO3Orc2nSUyrMq+FZtd9vC2Puf+zU8oEeP6mr4zHMBqZ 1KAhsyy4nKm9wWTy76GTxIPuydIthTPnTit0A= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aaNKLMJAmTCZyFXnNns5ajk6jDPL1+z744wLdDN6ieV/u2kDMgJ32JoXItxtUAvgmQ i7bKOr3Hl1GtJf4fNFffpEtTzMwl1aqwYpttuoE698y32wMR5BUhBZ/X9kaoMSbdYdTy 9nIQpb88uD60Y10F0WpJST9ItIQ4LoXrvzFIw= I told you this before... -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com Hi All, Thanks for all your inputs.I have checked the Xcode project settings.But there generate Position Dependent CodeĀ is unchecked.Is there anything else do I need to check ? My further observation looks like the system dynamic libraries, system frameworks names are coming incorrect but the frameworks developed by us names comes correctly. Any inputs would be very much appreciated. -A On Oct 6, 2009, at 10:25 AM, Arnab Ganguly <email@hidden> wrote: Hi All, Some inputs required. When an application crashes, what is the starting stack address Crashreporter gets as? Whatever is in the %esp/%rbp within the thread state struucture for each thread at the time the mach crash exception is thrown. We developed a similar crash app but when we compare the stack trace with the Crashreporter's there is a mismatch with initial stack addresses but after some traces it matches. Specially the traces very much internal to the system dynamic libraries doesn't match.Addresses related to Application it matches. Any inputs or pointers would be great help. That's because libraries are loaded at different locations on different machines and you still are not taking this into account with your crash report architecture, where you send the data back to your server for symbolication. Unless you save off specific task address space mapping locations for each, as part of the information you send back to your server, then your server will have different base addresses for the libraries and frameworks and therefore be unable to decode them properly. PS: It works for your main app only because you have not enabled ASLR for your app; if it is a network client or server, your app is likely vulnerable to buffer overflow and other attacks based on the fixed location of your code. Such an attack would work cookie-cutter fashion everywhere your software is deployed. By varying the address where it's loaded, you make it so an attack that works against one machine won't (statistically speaking) work against others. Admittedly, varying the location where system libraries are loaded is only protection if your app doesn't always load a vtable pointing at framework entry points into the same location on every machine, so that the same call sites exist everywhere (it kind of defeats the purpose if you do that in fact).
participants (1)
-
Arnab Ganguly