crash: cannot resolve "schedulers" crash-utility 7.1.5 withxen-4.7.0
by Guido.Rossmueller＠gdata.de
Hello everyone,
i have a problem with crash-utility 7.1.5 and xen 4.7.0
i have installed the kexec-tools for saveing the vmcore in case of a
Hypervisor crash. If i simulated this via xl debug-key C, i get the vmcore.
now, if i want to analyze this vmcore via crash:
crash --hyper /usr/lib/debug/xen-syms-4.7.0 vmcore
i got the follwing message:
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
crash: cannot resolve "schedulers"
if i execute this command with debug output:
crash -d3 --hyper /usr/lib/debug/xen-syms-4.7.0 vmcore
i got the follwing:
gdb /usr/lib/debug/xen-syms-4.7.0
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
GNU_GET_DATATYPE[note_buf_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_core_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_info_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_info_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_info_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[xen_crash_xen_regs_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[note_buf_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_t]: returned via gdb_error_hook
GNU_GET_DATATYPE[crash_note_xen_core_t]: returned via gdb_error_hook
sp=ffff8300e7507fc0, cpu_info=ffff8300e7507f18
sp=ffff830c14ec7fc0, cpu_info=ffff830c14ec7f18
sp=ffff830c14e6ffc0, cpu_info=ffff830c14e6ff18
sp=ffff830c17ee7fc0, cpu_info=ffff830c17ee7f18
sp=ffff830617feffc0, cpu_info=ffff830617feff18
sp=ffff830617fdffc0, cpu_info=ffff830617fdff18
sp=ffff830617fd7fc0, cpu_info=ffff830617fd7f18
sp=ffff830617fc7fc0, cpu_info=ffff830617fc7f18
idle_vcpu=ffff8300e72fe000, domain=ffff830c17ef8000
crash: cannot resolve "schedulers"
under xen 4.6.0 with crash-utility 7.1.5
it works.
have anybody tips or hint´s what the problem is and how to solve it.
all the best
guido
____________
Virus checked by G Data MailSecurity
Version: AVA 25.8092 dated 30.08.2016
Virus news: www.antiviruslab.com
8 years, 2 months
compiling statically?
by J Freyensee
Hi,
I just downloaded the latest crash code, and I would like to be able to
compile it statically. I tried doing
"make LDFLAGS="-static -static-libgcc"
but I don't think that worked because I got quite a few of these type
of warning messages:
(example)
crash/extensions.c:253: warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
crash/gdb-7.6/gdb/./common/linux-osdata.c:225: warning: Using
'getpwuid' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking
How could I compile crash as a static, 1 big exe?
Thanks for the help!
8 years, 3 months
Benefit of enabling CONFIG_DEBUG_INFO_DWARF4
by Nikolay Borisov
Hello,
I'd like to ask whether the crash utility would actually benefit from
enabling CONFIG_DEBUG_INFO_DWARF4 in the kernel when debugging a crash
dump. And by "benefit" I mean "better" output when disassembling
function etc?
Regards,
Nikolay
8 years, 3 months
[PATCH] Fix for swap used percentage reporting when totalswap_pages is 0.
by John Siddle
Without the patch, when totalswap_pages is 0, swap used percentage
reports as 100%. This is confusing on first glance as it seems to
indicate potential memory pressure. Fix this and also fix indentation on
'pct' calculations to improve readability.
---
memory.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/memory.c b/memory.c
index e994d13..f39c667 100644
--- a/memory.c
+++ b/memory.c
@@ -8302,12 +8302,12 @@ dump_kmeminfo(void)
fprintf(fp, "%13s %7ld %11s ----\n",
"TOTAL SWAP", totalswap_pages,
pages_to_size(totalswap_pages, buf));
- pct = totalswap_pages ? (totalused_pages * 100) /
- totalswap_pages : 100;
+ pct = totalswap_pages ? (totalused_pages * 100) /
+ totalswap_pages : 0;
fprintf(fp, "%13s %7ld %11s %3ld%% of TOTAL SWAP\n",
"SWAP USED", totalused_pages,
pages_to_size(totalused_pages, buf), pct);
- pct = totalswap_pages ?
+ pct = totalswap_pages ?
((totalswap_pages - totalused_pages) *
100) / totalswap_pages : 0;
fprintf(fp, "%13s %7ld %11s %3ld%% of TOTAL SWAP\n",
--
2.7.4
8 years, 3 months
[Crash-Utility] extensions/trace: Add support for multiple ftrace buffers
by Kyle Tomsic
This is my first time submitting a patch to a mailing list, so please be
patient with me if I've made any mistakes.
Since the 3.10 release, the Linux kernel has offered the ability to create
multiple independent ftrace buffers. At present, however, crash is only able to
extract the primary buffer. These patches seek to change that. All of the data
is already collected in the vmcore file; crash just isn't currently extracting
it.
I've split this changeset up into two pieces to address this. This first part
shouldn't lead to any change in functionality; it simply refactors the trace
extension so that the global instance is passed around as a parameter rather
than accessing it directly. That facilitates the second part, which locates all
of the available instances and extracts the data from each of them.
My testing has only included vmcores collected from 32-bit ARM systems, but I
don't believe I have made any assumptions about the architecture in my code.
Kyle Tomsic (2):
Refactor trace extension to pass trace information as an argument
Add support for multiple ftrace instances to trace extension
extensions/trace.c | 430 +++++++++++++++++++++++++++++++++++++++++------------
1 file changed, 333 insertions(+), 97 deletions(-)
--
2.9.2
8 years, 3 months
