7:35 p.m.
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
}
}
==============
P.S. speaking of dead horses: were the fprintf(fp...) placed *before*
the command pipe redirection (like when the command had just been read
in and not yet scanned), *THEN* the output would go to the right place.
Here, the command scanning just goes off into the weeds and misses the
pipe operator entirely.
2:34 p.m.
----- 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...
In the meantime, you should be able to use "px" instead of "p/x".
Dave
3:36 p.m.
Hi Dave,
On Tue, Feb 21, 2012 at 12:34 PM, Dave Anderson <anderson(a)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
3:40 p.m.
----- 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
4514
days inactive
4517
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Bruce Korb -
Dave Anderson