----- Original Message ----- > 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... I don't believe so either -- the patch makes good sense. Thanks for tracking that down. Strange that it would only "break up" the 2nd, 4th, 6th, etc. string arguments. I didn't bother trying to understand why that happens...) Queued for the next release. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
