[BUG] BitBlt crash
arning at charm.net
Sun Jan 30 02:19:54 UTC 2000
On Sun, 30 Jan 2000 00:27:54 +0100 Helge Horch <Helge.Horch at munich.netsurf.de> wrote:
>1.) add a RectangleMorph to a World and open an Inspector on it,
>2.) in the Inspector, change its bounds' extent to, say, (100/3)
>3.) summon restoreDisplay (BitBlt complains, and recommends to proceed)
>4.) proceed from the PreDebugWindow
>Repeat steps 3-4 until BitBlt gives up, and you get the error dump. Third
>time should do it.
>I examined BitBlt's self-healing code, and can't find any fault.
>Can anyone else shed light on this? Or is this only bad karma on my machines?
It's not you and it's not BitBlt. When you get an error while drawing a morph, the world (PasteUpMorph>>displayWorldSafely) tries to mark the morph in queation as having an error so that the drawing is not retried. This is where you will usually see the red rectangle with the yellow diagonals drawn. The problem here is that you messed up the morph's extent and so the attempted drawing of the red-and-yellow failed as well. At that point the world tries to widen the exclusion:
"If the morph causing the problem has already the #drawError flag set,
then search for the next morph above in the caller chain."
sooner or later this will fail and a fatal error will be the result. Below is a fix to allow your example to proceed benignly, but more could be done, perhaps a more thorough check of <bounds> in case it's <nil> or has non-numeric components.
'From Squeak2.7 of 5 January 2000 [latest update: #1789] on 29 January 2000 at 9:13:53 pm'!
!Morph methodsFor: 'drawing' stamp: 'RAA 1/29/2000 21:13'!
"The morph (or one of its submorphs) had an error in its drawing method."
bounds _ bounds truncated. "catch one cause of recursive errors"
fillColor: Color red
borderColor: Color yellow.
aCanvas line: bounds topLeft to: bounds bottomRight width: 1 color: Color yellow.
aCanvas line: bounds topRight to: bounds bottomLeft width: 1 color: Color yellow.! !
More information about the Squeak-dev