----- Original Message -----
>
>
> ----- Original Message -----
> > crash> p/x *(*(struct trace_page*)0xFFFF8804125CBA60).page | sed
> > 's/^\$[0-9]* =/0xFFFF8804125CBA60 =/' >> trace-data.txt\n
> > 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
Index: gdb_interface.c
===================================================================
RCS file: /net/homedirs/vol/data/share/projects/cvs/crash/gdb_interface.c,v
retrieving revision 1.56
diff -u -r1.56 gdb_interface.c
--- gdb_interface.c 9 Dec 2011 19:26:47 -0000 1.56
+++ gdb_interface.c 21 Feb 2012 21:28:58 -0000
@@ -758,9 +758,9 @@
if (pc->redirect & (REDIRECT_TO_FILE|REDIRECT_TO_PIPE)) {
p1 = strstr_rightmost(buf, args[argcnt-1]);
p2 = p1 + strlen(args[argcnt-1]);
- if ((p1 = strstr(p2, ">")) ||
- (p1 = strstr(p2, "|")) ||
- (p1 = strstr(p2, "!")))
+ if ((p1 = strstr(p2, "|")) ||
+ (p1 = strstr(p2, "!")) ||
+ (p1 = strstr(p2, ">")))
*p1 = NULLCHAR;
strip_ending_whitespace(buf);
}
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
