[Crash-utility] bt: cannot determine starting stack pointer

Bruce Korb bruce.korb at gmail.com
Tue Feb 14 21:14:49 UTC 2012


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




More information about the Crash-utility mailing list