[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