> Date: Thu, 21 Mar 2013 19:29:29 +0300
> From: Sergey Poznyakoff <[email protected]>
> Cc: <[email protected]>
>
> Eli Zaretskii <[email protected]> ha escrit:
>
> > The stand-alone Info reader crashed on me today when I did
> > index-search. Debugging that, I found a faulty logic in indices.c,
> > which caused us to write outside of a string's bounds when we up-case
> > or down-case a partial match found by index-search. The result was
> > that the following call to 'free' crashed.
>
> Can you please give a recipe of how to reproduce this?
Assuming you have gdb.info on your system:
info -f /usr/share/info/gdb.info
i bini RET
If it crashes right there and then, you have your repro. ;-) If not,
look at the echo area, which says:
Found `.gdbinit' in Concept Index. (`,' tries to find next.)
It should have said
Found `.gdBINIt' in Concept Index. (`,' tries to find next.)
like 'info' from 4.13 did. In 5.1, the up-casing uses wrong indices
(see below), so it doesn't up-case the partial match, but instead
writes beyond the bounds of the 'match' array.
This code:
if (index_partial)
{
/* When looking for substrings, take care not to return previous exact
matches. */
for (i = index_offset + dir; (i > -1) && (index_index[i]); i += dir)
if (!index_entry_matches (index_index[i], index_search, search_len) &&
string_in_line (index_search, index_index[i]->label) != -1)
{
partial = 1;
break;
}
}
sets 'partial' to 1. And then this code:
if (partial && show_index_match)
{
int k, ls, start, upper;
ls = strlen (index_search);
start = partial - ls;
upper = isupper (match[start]) ? 1 : 0;
for (k = 0; k < ls; k++)
if (upper)
match[k + start] = info_tolower (match[k + start]);
else
match[k + start] = info_toupper (match[k + start]);
}
indexes 'match' with values that start at 'partial - ls', which is a
negative value, since index_search, the search string, is generally
longer than 1 character.
