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
