[Crash-utility] RFC: Improving crash's search speed

[Bob Montgomery]

On Wed, 2011-01-26 at 20:29 +0000, Dave Anderson wrote:

> 
> I've pretty much got -p working OK, and next I'll plug in the -KVM restrictors. 

By the way, thanks for running with this.


>  
> > Today I'm trying to find out why parse_line() is messing up when given
> > more than one string in ""'s.
> 
> Not sure I understand how you can do that, but don't let me interfere...

The syntax for the search command:
    search [-s start | -k | -u] [-e end | -l length] [-m mask] value ...

allows multiple values for simultaneous search.  For example:

crash-5.1.1str>  search -k 00007ffffd401e28  00007f29a0cbeb9f
ffff88011e889f70: 7ffffd401e28
ffff88011e889fd8: 7f29a0cbeb9f

I thought I'd use a similar syntax for strings (-c for "chars", looking
for a better letter, maybe -S):

crash-5.1.1str> search -k -c "Memory value expected" "No such file or"

The current version of parse_line in tools.c has a problem with repeated
strings, so that it delivers the following in the value[] array:

(gdb) p value[0]
$1 = 0xb74a04 "Memory value expected"
(gdb) p value[1]
$2 = 0xb74a1b "\"No"
(gdb) p value[2]
$3 = 0xb74a1f "such"
(gdb) p value[3]
$4 = 0xb74a24 "file"
(gdb) p value[4]
$5 = 0xb74a29 "or\""

With the attached patch, it delivers:

(gdb) p value[0]
$1 = 0xb77a24 "Memory value expected"
(gdb) p value[1]
$2 = 0xb77a3c "No such file or"

I don't think it messes anything else up...

Bob Montgomery




-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse_line_strings.patch
Type: text/x-patch
Size: 726 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20110126/21a5b82a/attachment.bin>