FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 02-21-2012, 07:34 PM
Dave Anderson
 
Default Another parsing bug -- likely confusion caused by open parenthesis

----- 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...

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
 
Old 02-21-2012, 08:40 PM
Dave Anderson
 
Default 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
 

Thread Tools




All times are GMT. The time now is 12:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org