change to /sys/src/9/pc/bbmalloc.c

[forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk]

vortex% diff $home/cd/9/pc/bbmalloc.c .
82c82
< 	return 0;
---
> 	return u!=0;
88d87
< 	USED(len, onstack);
89a89,90
> 	if(!onstack)
> 		bbfree(memstart, len);

the key part is the bbfree; the onstack changes simply make
use when possible of an array that's allocated on the stack anyhow.
mind you, that also helps to avoid the underlying problem.

which is:

without the bbfree, bbmalloc returns blocks of Progmax bytes
from each of two 16k arenas in a strictly circular fashion.
the problem arises when a process doing a bitblt is suspended
during the bitblt, and another process (or an interrupt, on the pc)
also does one or more bitblts before the original bitblt is resumed.
i added some counters here and there to find that in practice there
were only ever 2 processes active in the bbmalloc arena[0] at any one
time, but that was enough, since one of them did enough bitblts
(and thus bbmallocs) to cause the 3k allocation to cycle round the arena,
eventually overwriting the first process's bitblt code.

	Weinberl: Well, a little forward.
	Mrs Fischer: A little?  You're in danger of meeting yourself coming back.
		``On the Razzle'', Tom Stoppard.

on the PC, because mousescreenupdate() enables interrupts during vgaupdate,
it's possible for cursor movements to be done using bbmalloc allocations
out of arena[0], which explains why messing about with the cursor in
a scroll bar was the easiest way to crash the system.