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

[Dave Anderson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb_interface.patch
Type: text/x-patch
Size: 750 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20120221/856acc0b/attachment.bin>