Hi Dave,
On Tue, Feb 14, 2012 at 11:07 AM, Dave Anderson <anderson(a)redhat.com> wrote:
> I need the stack traces of the tasks that are on-proc as well as
the
> tasks that are not. "bt" fails for the on-proc tasks, even though there
> is a backup mechanism for finding the stack:
You could also try "bt -t" or "bt -T".
That gets you too much information. You get anything in the stack
that resolves to
some symbol. (assuming I've understood the help text correctly).
Typically, there is a bunch of uninitialized stuff on the stack that
will often be return addresses to procedures that were in the stack
the last time
the stack got up to where you are. Using the task structure's stack
pointer gives
you a better shot at following the stack.
But what kind of dumpfile was this anyway? I'm wondering why you
aren't
getting any stack traces at all for the active tasks?
CFS (Cluster File System aka Lustre) appliance. As for why, I don't
exactly know.
I'd have to fetch crash sources and see that is going on where that message
gets emitted.
BTW, I've also tripped over a command parser bug. I wrote a script
intended to be used thus:
crash> !bash live-bt.sh
crash> < cmd
crash> < cmd
crash> < cmd
with the result being the back traces I'm after. For some reason, the
scanner went past the
end of an input line and found left over characters from a previous
input line, with two consequences:
1. an ugly error message saying that garbage was not a valid crash command
2. a message instructing the user to type "< cmd" was interpreted as a
command (sans quotes),
resulting in only needing to type the "< cmd" thing twice instead
of three times.
It's nice in a way, but probably not right. :)
I can send you new command line scanner/lexer code that is about 1/2
the current size tonight.
(Borrowed from my own open source hacking around.)