Thanks everybody for the explanation. I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row larger than needed and when converting discard one row.
The code looks more stable now. The test was up for about 30 minutes before crashing instead of 1 minute before the fix. Is it the right code change or just a coincidence? AthensCairoSurface>>asForm "create a form and copy an image data there" self checkSession. self flush. ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Tx igor I added > > https://pharo.fogbugz.com/f/cases/19764/Improve-comment- > of-AthensCairoSurfaceForm > > On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >> and i was dealing with it by adding 1 extra line to cairo surface, >> but reporting 1 less to Form. Like so, bitblt still reads past the >> allowed size, but it is safe, because there are unused bit(s). >> >> On 27 February 2017 at 20:31, Igor Stasenko <siguc...@gmail.com> wrote: >> >>> >>> >>> On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> the problem wit Ronie’s fix is that (as he says) you are copying >>>> another time the surface, before passing it to the VM (who makes >>>> yet-another-copy) so this is not optimal… and you can see it when running >>>> the Tiger demo: there are a lot of pauses. >>>> So I would prefer the other approach he suggests: >>>> >>>> Form subclass: #AthensCairoSurfaceForm >>>> instanceVariableNames: 'surface' >>>> classVariableNames: '' >>>> package: 'Athens-Cairo' >>>> >>>> AthensCairoSurfaceForm>>surface >>>> ^ surface >>>> >>>> AthensCairoSurfaceForm>>surface: anObject >>>> surface := anObject >>>> >>>> AthensCairoSurface>>asForm >>>> "create a form and copy an image data there" >>>> self checkSession. >>>> self flush. >>>> ^ (AthensCairoSurfaceForm extent: (self width@self height) >>>> depth: 32 bits: id) >>>> surface: self; >>>> yourself >>>> >>>> that seems to work. Can you try and see? >>>> >>>> >>> Btw, remember the culprit there , that you must have extra word in >>> trailing buffer space, >>> this is because bit-blt using read-ahead . Which is OK for objects >>> located in object memory, >>> since there are always something past the last object (unallocated >>> space), >>> but not so ok for buffers allocated by malloc (such as cairo surface >>> bitmap), and so, >>> if you read even a single byte past it, you get protection fault. >>> >>> >>>> Esteban >>>> >>>> > On 24 Feb 2017, at 15:47, stepharong <stephar...@free.fr> wrote: >>>> > >>>> > Hi alex >>>> > >>>> > can you try the fix of ronie and let us know if it makes roassal more >>>> stable? >>>> > >>>> > Stef >>>> > >>>> >> Dear Alexander, >>>> >> >>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. This >>>> is a pity, but fixing this is not trivial at all (we have been trying for >>>> years). >>>> >> >>>> >> What exactly are you doing with Athens? >>>> >> >>>> >> Alexandre >>>> >> >>>> >> >>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>> samoylov...@gmail.com> wrote: >>>> >>> >>>> >>> Hello >>>> >>> >>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>> reliably. >>>> >>> I believe the behavior is reproducible. >>>> >>> How should I report a bug? >>>> >>> >>>> >>> Alex >>>> >> >>>> > >>>> > >>>> > -- >>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >
