----- "Dave Anderson" <anderson@xxxxxxxxxx> 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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
