Panic in splitsect() under some conditions

[siebenmann]

I've been getting periodic samterm panics for some time on a machine I use sam on over ssh -X, always in splitsect(), with a consistent call chain of main() -> type() -> hgrow() -> rresize() -> findsect() -> splitsect(). With the aid of core dumps and staring at gdb, I have a reproduction case that goes like this:

1. start sam (& samterm)
2. 'New' a buffer and type some text into it. Make sure your cursor is at the end of the text
3. Use xdotool to inject a pair of keystroke events to samterm: xdotool search --class Sam key --delay 0 space BackSpace
4. samterm will panic in splitsect()

What I think is happening here is that the delete is processed first before the if (p > buf) { .... } grows the buffer. The delete shrinks the buffer, making the position in the buffer that cmdelbs() returns now be beyond its end, and then everything explodes. You may get more subtle explosions if multiple keystrokes are processed at once with other commands at their end.

It appears to me that the current type() may not work very well if commands are processed after other keystrokes. There seems to be a general assumption that the state of various (local) variables remains either correct or unimportant after the command is processed so that the if (p > buf) {...} code still works as expected, and that seems dangerous. But I'm somewhat fishing around in ignorance here.

[siebenmann]

I have a fix that appears to work for me, which you can now see in the linked commits (take the last one). However, I'm not a big user of binding commands to keys, so I'm not sure if my fix has side effects for more extensive use of them, and I don't entirely understand the command processing code here. Probably someone who does understand the code better should take a look and do more testing.