[Crash-utility] Another parsing bug -- likely confusion caused by open parenthesis

[Bruce Korb]

Hi Dave,

On Tue, Feb 21, 2012 at 12:34 PM, Dave Anderson <anderson at redhat.com> wrote:
> I'm not sure what you mean about the "open parenthesis", but I think

I looked at "expression" handling.  Once an open parenthesis is recognized,
the scanner goes into "expression" mode and leaves that mode when a closing
parenthesis is encountered.  Since the expression includes nested parentheses,
that means that whatever it is that "expression" state means must, perforce,
be confused after encountering the first of two closing parentheses.
That's a kind-of verbose description, so I hope its clear.

> this simpler example shows the problem, which is related to using
> a native gdb command in conjunction with a pipe and a redirect.
>
> The "p" command is sort of a "convenience" crash command that pretty
> much exists to be able to quickly change the output radix before passing
> the request to the gdb module.

I got that much out of it.  I figured (without code reading) that the
entire command
line would be more-or-less passed on directly to the GDB interpreter without
much muss or fuss on crash's part.  Obviously wrong.

> Piping the output works:
>
>  crash> px jiffies | cat
>  jiffies = $14 = 0xfffcc009
>  crash>
>
> Piping the output, and then redirecting it works:
>
>  crash> px jiffies | cat > /tmp/junk
>  crash> !cat /tmp/junk
>  jiffies = $15 = 0xfffcc009
>  crash>
>
> But using the gdb "p/x" command directly (bypassing the crash "p"
> command), in conjunction with a pipe and a redirect, generates the
> failure.  Just a pipe or a redirect alone works OK:

Yep.  That was what I noticed.  I really do think that the redirection
code needs to be thought over a bit more.  Another problem I discovered
while creating 100's to 1000's of ``crash-cmd | shell-cmd >> outfile'' thingys
was that the pipe would occasionally hiccup.  That hiccup would put a
really nasty belch into the "outfile" that was impossible to accommodate.
In the end, my new paradigm is:
    crash-cmd > unique-file-name
and when they're all done, run some code that fiddles with each of these
gazillion files, none of which will contain command trace output nor error
messages.  They will all go to the correct FD.

I think command tracing needs to be done before command output redirection
and I think that error reporting needs to happen on an error reporting
fd (e.g. stderr).
Meanwhile, I'll just use gazillions of files.

> Not sure why just yet, other than there's a difference in the way
> native gdb commands and crash commands are processed.  Let me dig
> into it...

OK, thank you.  I'd likely be easier if you just scanned the input line for an
end-of-crash-command mark (redirection or pipe) and the code wrapping the
gdb commands would never need to know anything about what happens after
the '|' or '>' character, or even that there was one.  That was probably your
intent and something got in the way.....

Cheers - Bruce