[Crash-utility] Problem on getting kernel backtrace with a `virsh dump' dumped kvm dumpfile

[Dave Anderson]

----- "Dave Anderson" <anderson at redhat.com> wrote:

> If the backtrace above occurs with the user-space-endless-loop
> dumpfile, then it's not necessary to send them to me.  But if the
> bt errors still occur with the dumpfile containing the user-space
> endless-loop (and with no System.map), then yes, I would like to
> see the vmlinux/dumpfile pair.  (You can send the download details
> off-list...)

Hu Tao,

I reproduced this by using the "correct" System-map file for a KVM
guest dumpfile -- which I presume that you also did in your test 
as well. 

Even though it is not recommended to use a System.map file as 
a command line argument -- *unless* the vmlinux file is different
from the kernel that caused the crash -- I was surprised that
doing so resulted in the "bt" errors when using the "correct" 
System.map, because the symbols that get back-patched during
initialization would be the same values.

As it turns out, it is a bug.  However, it will only be seen if you
use a System.map file.  Nonetheless, it should not happen when
the System.map file matches the crashed kernel's vmlinux.

The bug is in the is_kernel_text() function, which is incorrectly
returning TRUE on non-kernel text addresses in kernels where
the __per_cpu_start value is no longer a large absolute value well
beyond _etext, but changed to a low offset value.  For example, in
older kernels, it used to be an absolute (A) value like this:

  ffffffff80419000 (A) __per_cpu_start

But in newer kernels it is zero-based (D) value:

  0 (D) __per_cpu_start

And that bug is what's causing the "bt" command to fail.

In any case, I'll fix it in the next release.

But -- as is always the case -- do *not* use a System.map file
as an argument unless it is absolutely necessary!

Thanks,
  Dave