vm crash from BalloonEngine (maybe B2DPlugin or BitBltPlugin)

Confirmed.

Karl

On Wed, Apr 8, 2015 at 5:33 PM, Nicolai Hess <[hidden email]> wrote:

In order to reproduce it, draw a rectangle with radial gradient fill, with direction

and normal, both of length 1.

This one works (no vm crash):
|form canvas fill direction normal|
direction := 1@0.
normal := 0@0.
form := Form extent:300@300 depth:32.
canvas := form getCanvas.
fill := GradientFillStyle new colorRamp:{0 -> Color white . 0.5 -> Color green . 1 -> Color blue};origin:150@150;direction:direction;normal:normal;radial:true;yourself.
canvas fillRectangle: (50@50 extent:200@200) fillStyle: fill.
Display getCanvas drawImage: form at: 300@300.


direction := 1@0.
normal := 0@0.

-> OK

direction := 0@0.
normal := 0@1.

-> OK

direction := 1@0.
normal := 0@1.

-> VM-Crash (Pharo and Squeak)

Pharo:
VM Version: Cog VM 4.0.0 (release) from Feb 16 2015
Compiler: gcc 4.6.2
Interpreter Build: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015
Cogit Build: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015
Source Version: https://github.com/pharo-project/pharo-vm.git Commit: 55fbd0b0279998a4a33852f5afb3d213986cc3ae Date: 2015-02-16 17:54:00 +0100 By: Esteban Lorenzano <[hidden email]> Jenkins build #14895

Current byte code: -1
Primitive index: 117
Smalltalk stack dump:
  0x24c830 M BalloonEngine>copyLoopFaster 0x6b09b80: a(n) BalloonEngine
  0x24c848 M BalloonEngine>copyBits 0x6b09b80: a(n) BalloonEngine
  0x24c860 M BalloonEngine>postFlushIfNeeded 0x6b09b80: a(n) BalloonEngine
  0x24c884 I BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 0x6b09b80: a(n) BalloonEngine
  0x24c8b8 I BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 0x6b099c0: a(n) BalloonCanvas
  0x24c8e8 I BalloonCanvas>fillRectangle:basicFillStyle: 0x6b099c0: a(n) BalloonCanvas


Squeak:

VM Version: Cog VM 4.0.0 (release) from Aug 22 2013
Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Interpreter Build: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
Source Version: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins

Current byte code: -1
Primitive index: 117

nicolai

You also get weird artifacts when the gradient orientation and normal is very small.

In attached image, orientation is 0@-1 and normal is 1@1

Karl

On Wed, Apr 15, 2015 at 10:34 PM, Nicolai Hess <[hidden email]> wrote:

2015-04-08 20:02 GMT+02:00 karl ramberg <[hidden email]>:

Confirmed.

Karl

On Wed, Apr 8, 2015 at 5:33 PM, Nicolai Hess <[hidden email]> wrote:

In order to reproduce it, draw a rectangle with radial gradient fill, with direction

and normal, both of length 1.

This is not the reason why it crashes. It happens for other values as well:

|form canvas fill direction normal|
direction := 4@0.
normal := 0@2.
form := Form extent:300@300 depth:32.
canvas := form getCanvas.
fill := GradientFillStyle new colorRamp:{0 -> Color white . 0.5 -> Color green . 1 -> Color blue};origin:400@400;direction:direction;normal:normal;radial:true;yourself.
canvas fillRectangle: (0@0 extent:800@800) fillStyle: fill.
Display getCanvas drawImage: form at: 300@300

This uses a different value for direction and normal and the fill is defined for a larger area (800x800) -> CRASH

Maybe, this is a rare bug, because, normally you don't create a small gradient t o

fill a large area. But a vm crash is not nice, I would like to get this

fixed.

I am not sure what is the exact cause, but it may come from a signed integer overflwo,

It looks like Balloon uses fixed point arithmetik (binary scaling).

This fixed point representation (16.16 bit fixed point represented in a 32 integer) tend

to overflow, especially for operations like computing the squared length of a vector

x*x+y*y -> overflow -> result is a negative number.

Possible solutions:

downscale prior to the multiplication -> lost of precision

use a larger datatype for intermediate results.

It looks like B2D uses the first option (look at senders of
accurateLengthOfwith

and

squaredLenghtOfwith

Maybe there is something wrong with the other code that

multiplies the values, or the 16.16 bit fixed point is just not

large enough for some fills?

Any ideas?

Nicolai

 

This one works (no vm crash):
|form canvas fill direction normal|
direction := 1@0.
normal := 0@0.
form := Form extent:300@300 depth:32.
canvas := form getCanvas.
fill := GradientFillStyle new colorRamp:{0 -> Color white . 0.5 -> Color green . 1 -> Color blue};origin:150@150;direction:direction;normal:normal;radial:true;yourself.
canvas fillRectangle: (50@50 extent:200@200) fillStyle: fill.
Display getCanvas drawImage: form at: 300@300.


direction := 1@0.
normal := 0@0.

-> OK

direction := 0@0.
normal := 0@1.

-> OK

direction := 1@0.
normal := 0@1.

-> VM-Crash (Pharo and Squeak)

Pharo:
VM Version: Cog VM 4.0.0 (release) from Feb 16 2015
Compiler: gcc 4.6.2
Interpreter Build: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015
Cogit Build: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015
Source Version: https://github.com/pharo-project/pharo-vm.git Commit: 55fbd0b0279998a4a33852f5afb3d213986cc3ae Date: 2015-02-16 17:54:00 +0100 By: Esteban Lorenzano <[hidden email]> Jenkins build #14895

Current byte code: -1
Primitive index: 117
Smalltalk stack dump:
  0x24c830 M BalloonEngine>copyLoopFaster 0x6b09b80: a(n) BalloonEngine
  0x24c848 M BalloonEngine>copyBits 0x6b09b80: a(n) BalloonEngine
  0x24c860 M BalloonEngine>postFlushIfNeeded 0x6b09b80: a(n) BalloonEngine
  0x24c884 I BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 0x6b09b80: a(n) BalloonEngine
  0x24c8b8 I BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 0x6b099c0: a(n) BalloonCanvas
  0x24c8e8 I BalloonCanvas>fillRectangle:basicFillStyle: 0x6b099c0: a(n) BalloonCanvas


Squeak:

VM Version: Cog VM 4.0.0 (release) from Aug 22 2013
Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Interpreter Build: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013
Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013
Source Version: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins

Current byte code: -1
Primitive index: 117

nicolai

 

On 15.04.2015, at 13:34, Nicolai Hess <[hidden email]> wrote:

|form canvas fill direction normal|
direction := 4@0.
normal := 0@2.
form := Form extent:300@300 depth:32.
canvas := form getCanvas.
fill := GradientFillStyle new colorRamp:{0 -> Color white . 0.5 -> Color green . 1 -> Color blue};origin:400@400;direction:direction;normal:normal;radial:true;yourself.
canvas fillRectangle: (0@0 extent:800@800) fillStyle: fill.
Display getCanvas drawImage: form at: 300@300

This uses a different value for direction and normal and the fill is defined for a larger area (800x800) -> CRASH

Maybe, this is a rare bug, because, normally you don't create a small gradient t o

fill a large area. But a vm crash is not nice, I would like to get this

fixed.

I am not sure what is the exact cause, but it may come from a signed integer overflwo,

It looks like Balloon uses fixed point arithmetik (binary scaling).

This fixed point representation (16.16 bit fixed point represented in a 32 integer) tend

to overflow, especially for operations like computing the squared length of a vector

x*x+y*y -> overflow -> result is a negative number.

Possible solutions:

downscale prior to the multiplication -> lost of precision

use a larger datatype for intermediate results.

It looks like B2D uses the first option (look at senders of
accurateLengthOfwith

and

squaredLenghtOfwith

Maybe there is something wrong with the other code that

multiplies the values, or the 16.16 bit fixed point is just not

large enough for some fills?

Any ideas?

No idea, but just as a datapoint:

The code works fine in SqueakJS (if you enlarge the form to actually show the ellipse centered at 400@400):

Also no idea why the gradient repeats after 260 pixels ...

- Bert -