I'm not sure what you mean about the "open parenthesis", but I think
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. Using just "p" alone defaults to the
current output radix (decimal by default):
crash> p jiffies
jiffies = $12 = 4294754313
crash>
The output radix can be changed by entering the "hex" alias,
and then the same command above. Or alternatively, either
"p -x" or the "px" alias can be used:
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:
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...
In the meantime, you should be able to use "px" instead of "p/x".
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
02-21-2012, 08:40 PM
Dave Anderson
Another parsing bug -- likely confusion caused by open parenthesis
----- Original Message -----
>
>
> ----- Original Message -----
> > crash> p/x *(*(struct trace_page*)0xFFFF8804125CBA60).page | sed
> > 's/^$[0-9]* =/0xFFFF8804125CBA60 =/' >> trace-data.txt
> > gdb: gdb request failed: p/x *(*(struct
> > trace_page*)0xFFFF8804125CBA60).page | sed 's/^$[0-9]*
> > =/0xFFFF8804125CBA60 =/'
> > crash> p/x *(*(struct trace_page*)0xFFFF8804125CBA60).page
> > $1467 = {
> > flags = 0x200000000000000,
> > _count = {
> > counter = 0x1
> > },
> > {
> > _mapcount = {
> > counter = 0xffffffff
> > },
> > {
> > inuse = 0xffff,
> > objects = 0xffff
> > }
> > },
> > {
> > {
> > private = 0x0,
> > mapping = 0x0
> > },
> > ptl = {
> > raw_lock = {
> > slock = 0x0
> > }
> > },
> > slab = 0x0,
> > first_page = 0x0
> > },
> > {
> > index = 0x0,
> > freelist = 0x0,
> > reserve = 0x0,
> > frag_count = {
> > counter = 0x0
> > }
> > },
> > lru = {
> > next = 0xdead000000100100,
> > prev = 0xdead000000200200
> > }
> > }
>
> Bruce,
>
> I'm not sure what you mean about the "open parenthesis", but I think
> 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. Using just "p" alone defaults to the
> current output radix (decimal by default):
>
> crash> p jiffies
> jiffies = $12 = 4294754313
> crash>
>
> The output radix can be changed by entering the "hex" alias,
> and then the same command above. Or alternatively, either
> "p -x" or the "px" alias can be used:
>
> crash> px jiffies
> jiffies = $13 = 0xfffcc009
> crash>
>
> 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:
>
> crash> p/x jiffies | cat
> $16 = 0xfffcc009
> crash> p/x jiffies > /tmp/junk
> crash> !cat /tmp/junk
> $17 = 0xfffcc009
> crash>
>
> But using a pipe and a redirect strips the redirect, but leaves the "| cat"
> attached to the end of the command line sent to gdb:
>
> crash> p/x jiffies | cat > /tmp/junk
> gdb: gdb request failed: p/x jiffies | cat
> crash>
>
> Interesting that several pipes can be used, with the same bug
> showing up:
>
> crash> p/x jiffies | cat | cat > /tmp/junk
> gdb: gdb request failed: p/x jiffies | cat | cat
> crash>
>
> 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...
Bruce,
The attached patch will address the above issue with native gdb command
handling -- although I suspect it will only be a matter of time before you
come up with another anomaly nobody's bumped into yet... ;-)
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility