[Crash-utility] x86_64: Function parameters from stack frames
Alexandr Terekhov
Alexandr_Terekhov at epam.com
Wed Jul 31 08:03:32 UTC 2013
Dave,
could you please set debug level (set debug 3) and run again
backtrace for core-files:
1. which generate segmentation violations
2. which contain repetitive `apic_timer_interrupt` frames
and send output to me.
On Tue, Jul 30, 2013 at 04:17:52PM -0400, Dave Anderson wrote:
...
> Of the 160, only 32 generated a backtrace. 115 of them just
> printed 2 or more "." characters and nothing else. What does
> that mean?
This mean that error occured while obtaining frames info.
> 2 of them generated "gdb request failed" failures trying to print
> tss_struct fields. And I should note that at first I tried "bt -aH",
> but almost every time I would get the same type of gdb request failures
> on the other active, non-crashing, cpus. So then I decided to just
> test it with a "bt -H".
`tss_struct` problem was fixed.
> And is there a reason for the special case for panic()? They all
> seem to show this:
>
> # 0: [RSP: 0xffff88001fb1dc10, RIP: 0xffffffff814c7be0] panic ( ... )
> < Argument list for symbol: panic
> RDI: 0xffffffff81644a6b, RSI: 0xffff88001fb1dd68, RDX: 0x9
> RCX: 0x30001, R8: 0x73, R9: 0x0
It is not case for panic() only, but for functions with a varying number
of arguments.
> Since you've already followed my original suggestion and segregated
> the code into its own file, can you take it one step further and transform
> it into an extension module? If you did that, then I could host it
> on the crash extensions web page for people to test/use.
Will do it a bit later.
> Thanks,
> Dave
Alexandr
More information about the Crash-utility
mailing list