[9fans] Reliable 9vx(.OSX) crash

[a@9srv.net]

Do this:
	acme -c1 -f /lib/font/bit/courier/latin1.7.font /lib/kana
Put the mouse in the kana window and scroll down. For me, this
reliably crashes 9vx. Running with -t, I get:
	84 acme fault 0 no segment
	segment 0xf000000 0x10000000
	segment 0x1000 0x42000
	segment 0x42000 0x4c000
	segment 0x4c000 0x99000
	84 acme: unhandled fault va=0 [11000000] eip=3bcdd
	cpu0: registers for acme 84
	FLAGS=0 TRAP=0 ECODE=0 PC=3BCDD USP=8FF00
	  AX 00000000  BX 0008FE02  CX 00000052  DX 0008FEB0
	  SI 00000000  DI 00048646  BP 00000000
	56384: signal: sys: abort
This 9vx is post-0.12; I don't have any other systems to try 9vx
on, so I can't say if it shows up elsewhere. A recent drawterm to
an up-to-date (within ~3 days) kills acme with the following:
	stringwidth: bad character set for rune 0x0000 in /lib/font/bit/courier/latin1.7.font
	stringwidth: bad character set for rune 0x0000 in /lib/font/bit/courier/latin1.7.font
	acme: end of string in frcharofpt: '/env/mousescrollsize' file does not exist
	acme 39441: suicide: sys: trap: fault read addr=0x0 pc=0x0003bcdd
but drawterm and the cpu server are unharmed. I'm not sure,
but suspect the "/env/mousescrollsize" error is a bug; I think
it's printing the wrong error. Setting mousescrollsize changes
the error to
	acme: end of string in frcharofpt: '/lib/font/bit/courier/R.7.1.0' file does not exist
(which is true, although I'm not sure why it's looking for it;
courier/latin1.7.font just says 0x0000 to 0x00FF are in
R.7.1, which does exist).

Within 9vx, something is printed which looks like the same
message from the drawterm'd crash, but goes away before I
can be sure.
Anthony