Re: Bug: Searching through sufficiently large $historywords causes seg fault

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> Tracking down all possible cases where a history word number can be
> calculated wrongly from any possible source is another thing entirely.
> Possibly some DPUTS() in the earlier code are a good idea, as now we
> know it is showing up in error later on trapping it there isn't going
> to help any more.

Here's the only obvious case I can see in normal history management
where you might get a miscalculation, though why is obscure as this
seems only to be connected to skipping a !-history expansion.  IF
this pops up hopefully you'll be able to work out how to reproduce
it.

The history reading mechanism from a file remains a suspect as it's
much more obscure, and is consequently harder to instrument usefully.

I'll commit the other patch this weekend: I think we have enough
information to be able to continue searches without having to have
the shell crash for us.

pws

diff --git a/Src/hist.c b/Src/hist.c
index 82d03a840..7e6394406 100644
--- a/Src/hist.c
+++ b/Src/hist.c
@@ -1643,12 +1643,17 @@ hend(Eprog prog)
 void
 ihwbegin(int offset)
 {
+    int pos = hptr - chline + offset;
     if (stophist == 2 || (histactive & HA_INWORD) ||
 	(inbufflags & (INP_ALIAS|INP_HIST)) == INP_ALIAS)
 	return;
     if (chwordpos%2)
 	chwordpos--;	/* make sure we're on a word start, not end */
-    chwords[chwordpos++] = hptr - chline + offset;
+    DPUTS1(pos < 0, "History word position < 0 in %s",
+	   dupstrpfx(chline, hptr-chline));
+    if (pos < 0)
+	pos = 0;
+    chwords[chwordpos++] = pos;
 }
 
 /* Abort current history word, not needed */