site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com William Kucharski writes:
On Dec 22, 2004, at 7:03 AM, Andrew Gallatin wrote:
Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x00000000000000D4 PC=0x0 00000000002CAE8 Latest crash info for cpu 1: Exception state (sv=0x1DD39000) PC=0x0002CAE8; MSR=0x00001030; DAR=0x000000D4; DSISR=0x40000000; LR=0x0002 CAD8; R1=0x0CC33DB0; XCP=0x0000000C (0x300 - Data access) Backtrace: 0x0002CAD8 0x0002C8A8 0x0002C870 Proceeding back via exception chain: Exception state (sv=0x1DD39000) previously dumped as "Latest" state. skipping... Exception state (sv=0x009D8500) PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x0000 0000; R1=0x00000000; XCP=0x00000000 (Unknown)
First, update to a new kernel! You're still running 10.3.4!
I did that on my on, "just in case". But I'm pretty sure its our fault.
Second, the stack pointer (%r1) has been zeroed. The DAR would be what one would expect as the instruction is probably an access of 0xD4 off the stack.
Have your programmers check to make sure they aren't accidentally stomping on %r1 or the save area %r1 is normally restored to before a "blr"...
Thanks for the details, but I'm not very familiar with the ppc architecture. What's a common programming error that can result in this behaviour on ppc? Could returning from a function after it clobbers the stack result in this behaviour? If so, are there any "red-zone" options in the Darwin kernel that could catch something like this? Thanks, Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com