# file *
console-20111031: data
console.c0-0c0s5n1: ASCII Java program text
dump.000051: data
hosts: ASCII English text
live-bt.sh: Bourne-Again shell script text executable
lnet_kos: directory
lustre_kos: directory
README: ASCII English text
System.map: ASCII text
vmlinux: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), statically linked, not stripped
> No, I meant what was the dumpfile format, i.e., was it an ELF kdump,
> compressed-kdump, Xen dump, kvmdump, etc?
I don't actually know what the acquisition method was.
> The error message is from here, where the starting stack pointer
> could not be determined, or was an address that is not accessible
> for some reason:
>
> if (!(bt->flags & BT_USER_SPACE) && (!rsp || !accessible(rsp))) {
> error(INFO, "cannot determine starting stack pointer\n");
> if (KVMDUMP_DUMPFILE())
> kvmdump_display_regs(bt->tc->processor, ofp);
> else if (ELF_NOTES_VALID() && DISKDUMP_DUMPFILE())
> diskdump_display_regs(bt->tc->processor, ofp);
> else if (SADUMP_DUMPFILE())
> sadump_display_regs(bt->tc->processor, ofp);
> return;
> }
With the dumps we get, it happens essentially all the time.
My bizarre shell loops were a function of writing to the same file
bash was reading from.....With that fixed, I now have a template
for writing multi-pass shell scripts.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
