Hi Dave, On Tue, Feb 14, 2012 at 11:07 AM, Dave Anderson <anderson@xxxxxxxxxx> 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.)
Attachment:
live-bt.sh
Description: Bourne shell script
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
