Re: [Crash-utility] RFC: string search for crash
----- Original Message -----
Here is a patch to add string search to crash-5.1.1.
It requires the my previous patch for the parse_line routine.
It searches for the specified strings, and for half or more of the
string appearing at the start and end of search blocks (usually pages)
in case the string spans a page boundary.
It is currently invoked with the -c option to search, as in:
crash-5.1.1str> search -k -e 0xffffc90000000000 -c "getty[3895]"
ffff880123b54810: :46 getty[3895]: /dev/ttyS1: No such file or dir
or
crash-5.1.1str> search -k -c -e 0xffffc90000000000 "getty[3895]"
ffff880123b54810: :46 getty[3895]: /dev/ttyS1: No such file or dir
It reports the found string in 48 chars of context (except
at the end of pages), and it reports aligned addresses, so the found
string doesn't always appear at the beginning of the context (as in the
example above).
It could optionally use strncasecmp to do case-insensitive searches.
I simplified it :-) by combining the main and tail searches into one
loop and added a 10-15% performance degradation somewhere.
Here it searches the dump for bugs and danger :-)
crash-5.1.1str> search -k -c -e 0xffffc90000000000 "bugs"
"danger"
ffff8801254c0ff8: ug:Debug
ffff880125cd4ff8: ebian/bu
ffff880125ec8870: efb: danger danger! Oopsen imminent!..<6>Mode (%
ffff880125ec8878: ger danger! Oopsen imminent!..<6>Mode (%dx%d) la
ffff880125eee518: ofb: danger danger! Oopsen imminent!..<3>neofb:
ffff880125eee520: ger danger! Oopsen imminent!..<3>neofb: neo2200
ffff880125f72000: ger_event.......................................
ffff880125fc3560: ice bugs (default = 0, 128kB max transfer = 0x1,
The first two hits come because half or more of "bugs" occurred at the
end of a page. The next to the last hit is found because the last
half of "danger" appears at the beginning of a page.
Bob Montgomery
Hi Bob,
A couple things...
First, this is a really nifty feature...
Second, I appreciate that you created a new string_search() function
instead of attempting to merge it into the existing search() function.
I'm doing the same thing for implementing the "-p" functionality because
physical addresses may require 64-bit start/end addresses on 32-bit machines,
However, I did have to change cmd_search() to use ulonglong's for start
and end. Then trying to shoe-horn physical memory searching into
the existing virtual-memory-presuming search() command was way too ugly
to consider.
Third, given that you're searching for specific string, why not show
the actual byte-aligned address as the starting point, and then just
display the string contents until the next non-ASCII character, or some
other delimiter like a 48 byte limit or whatever?
I understand that the page-crossing issue is a PITA, but with respect
to a user searching memory for strings, the page-crossing issue is
seemingly irrelevant. In other words, why this:
ffff880125f72000: ger_event.......................................
instead of displaying something like this:
ffff880125f71ffd: danger_event
So I guess I'm just wondering why the "dan" at the end of the page
cannot be displayed? It just doesn't seem user-friendly to force
the user to understand the half-of-the-string-at-a-page-boundary
business. Since you do recognize that string exists and crosses
a page boundary, shouldn't you be able to display the first part?
Lastly, I'm still planning to add the remaining "search" command
updates for the -KVM flags and the "missing" x86_64 segment bug,
and so I may need you to re-work this patch to fit into an updated
version of search(). I've been delayed getting crash-5.1.2 out
the door because of all of the recent patch postings, and it may
be worth waiting to get this piece in until 5.1.3 -- is that OK
with you?
Thanks,
Dave