# 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.